Erroneous column shows up in every migration

This is my first time using Lightspeed migrations, and I seem to be having trouble with a column that Lightspeed wants to add in every migration.

Here's a screenshot of the create migration window, note that just prior to this I created another migration and accepted all offered changes to be added. You can also see that Lightspeed is not only suggesting a column that already exists and was added in the first migration, but it's down implementation is incorrect in that it attempts to Add the column when it should be dropping the column.

I started developing the application and database without using migrations. Several iterations of database changes were done manually, and I am now trying to automate the process.

First I created a migration and used every change shown so that the first migration represented the current state of the database schema. The ProductListId column and associated foreign key is in that migration, was added by Lightspeed, and the column nor table has not been changed since the first migration.

If I let Lightspeed create the migration pictured, then immediately create another migration with no other changes, the same column with the same incorrect Down action is offered again.

The Product version of Lightspeed in the Mindscape.Lightspeed.dll metadata is 4.0.1238.20149. I could upload project files or lsm checkpoint files if that is helpful - though combing through them myself I cannot see a reason for this behavior. I have not attempted to recreate the problem in a new, empty project and frankly doubt it would reappear if I did.

Any ideas? I can obviously unselect the action every time I create a migration, but I would hope there is a simple fix and I don't have to deal with that mental drag on development. Thanks!

No this does seems odd and sounds like a bug. Do you also get this change suggested if you try and synchronise the model against the database (or vice versa)?

Jeremy

No, I do not get these changes when syncing. Only when creating the migration.

So... this is weird. I pulled my changes to my home machine and now I get 3 fields (including the original) and one whole table (a MtM) doing the same thing. I'm almost hesitant to mention it because it's too odd and I wonder what I've screwed up here.

Here's the create window with the db diagram in the background.

There's only 3 checkpoint files and they're all there. The .diagram file had a couple changes that look like I just placed the endpoint of a relationship arrow differently, and while you can't see it both are in different entities from the 4 in the create migrations window.

I'm at a loss about the migrations suggested. But I can make model changes or db changes and sync both ways. Doing so does not affect the migrations. If I make additional changes to the model those migrations come through correctly (and go away after creating them).

Yes, very odd. Is it possible for you to send through a copy of your model project and migrations project for us to try and repro this here and have a dig into how its coming up with these recommendations. You can email this through to us support at mindscape.co.nz if thats a possibility.

Thanks!
Jeremy

I've sent a dropbox link to that address, it is a zip of the entire project.

Interestingly, that is the zipped up copy from my home PC. I opened that zip on my work PC this morning, and now it only shows the one original problem column. It only shows the 3 columns and a table on my home PC. So it would seem some part of this issue might live outside the project code files. Just let me know if there is any more information I can provide to assist you.

Thanks.

I don't know if its a result of the problem I've listed but I'm experiencing a couple other issues as I'm working with migrations.

After adding one column to a table and creating a migration I got an Up action but no Down action. After adding a table and a through association to it and creating a migration I got Up & Down for the table but nothing for the table that represents the through association.

And maybe this is better in another thread, but in my experience with Migrator.Net it had an API for running DDL statements like INSERT which I've used to populate tables initially (like a lookup table). Is there anything similar in Lightspeed? The migration API looks terribly thin.

Thanks - am just downloading the file now - I will let you know once I have had a look into this to see what I can find.

Jeremy

We dont have anything for handling data migrations - the migration framework is strictly focused on schema migrations for now. Its intended that you would pair this with your own code if you were wanting to do inserts at the same time. You could do this via ExecuteNativeCommand if you wanted to pre-generate and execute the raw SQL insert statements or you could do this by creating and persisting new entities (which would require referencing in your model etc).

Jeremy

Ah... thank you. I didn't consider using my model to do it.

I am trying to use some code to do the insert and this code needs to reference another DLL to read a csv file. When I try to run the migrations on our server the compilation fails because it cannot find the namespace contained in this 3rd party dll. The DLL is in the same folder as lsmigrate.exe and my migration source code files. It works fine when I run the migrations locally in Visual Studio. I cannot install this dll into the GAC because it is not strongly named.

I am still plagued by incorrectly generated migrations. Here this morning I added a column and still get the incorrect fields and no Down migration for the field I am adding.

I am also quite interested in how to run migrations from the command line where the migration references other assemblies? As I mentioned above it appears that the references cannot be found. Is there a way to use lsmigrate to run the migrations in an already compiled assembly, I assume that would do it?

Just wanted to update you on this. I have tracked down what is occuring here, many thanks for providing your project to help repro this.

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.

I am looking into how we can update things to resolve this and I will update you again once we have made some progress on a fix that we can get into the nightlies for you.

Jeremy