This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
We have this odd Lightspeed quirk that we've lived with now for eons. Everytime we make a new migration the migration window contains these same two changes which aren't real. They aren't real in that; the model doesn't differ from the database in that way. If we humour Lightspeed and create the migration then upgrade the database there is no effect. The next time we create a migration - guess what?! .... it suggests the same two changes again. Quirky, yet annoying. We have come to recognise this problem and we just know to unselect them every time we create a migration. But it's a pain in the tuchus! |
|
|
I think we have seen this before. Is Party an entity which has derived entities using STI and those changes relate to associations on derived classes (from the screenshots it would appear that this is the case?). If so then this would match with a known outstanding issue. To give a quick explanation of what is occuring, for migrations we perform a diff of the current model vs the model used for the last migration and determine the differences. This process is the same as when we do a database sync, but rather than using the last migration model we extract a representation of the model as seen in the current database to diff against. The error occuring here is that when diffing between the two models when determining the differences between the expected one to many models and actual one to many models, the association on the derived child is being missed so this is why it shows up. However when we do the database sync we pick up this association because its an STI table so both FK relationships are present leading to us incorrectly assuming something has changed. We have done some work into trying to fix this but unfortunately its going to be quite complicated to fix so for now we are treating this as a known issue that we dont intend to fix just yet.
|
|