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
|
Hi, I've just added a new entity (Theme) to my model which has a one-to-many association with the existing Project entity (one theme can link to many projects). My migration includes adding the Theme table to the DB, but it doesn't include adding the ThemeId field to the Projects table in the list of things to include in the migration. If I right click on my model and select 'Update Database' I see 'Add column ThemeId and associated foreign key to table Projects' which suggests to me that I should also see it in my migration. Is there a particular reason why this is happening? Am I doing something wrong or could this be a bug? I am fairly new to using migrations so I'm likely missing something. I'm currently using Lightspeed 4 2011-11-23 nightly build and the database is MSSQL 2008. Thanks Andrew |
|
|
You should also see it in your migration, and when I tested this it worked for me and generated the following migration code:
The only thing I can think of is that the migration baseline is not the same as the database baseline. For example, maybe the previous migration already included a ThemeId property, but the database didn't -- so when LightSpeed checks what changes are needed to the database, it sees that it needs to add ThemeId, but when it checks what changes have been made since the last migration, it sees no need to add ThemeId because it is already there. If this doesn't seem to be the case then could you post your model (including the new Theme entity and association) and the previous .lsmcheckpoint file from the migrations project, and we will try to see if there is a bug here. In the meantime, don't forget you can always edit the migration code, so you can insert the AddForeignKeyColumn call manually rather than being held up while we resolve this. |
|
|
Hi Ivan Thanks for the quick reply. I've rolled everything back to before I did this first migration and started again. When I select 'Create Migration' from the Migrations menu the "When migrating up" list has entries to create tables for every entity in the model, even though tables already exist in the database for most of them. If I deselect all of them and just select the Themes one then the Themes table is created and no ThemeId field is added to the Projects table. If I instead deselect them all and just select the entries for Themes and Projects then in the Up method I see code which creates the ThemeId ForeignKeyField, but unfortunately it's also creating the already existing Projects table. Is this the way you would expect it to work? Why do I see entries to create all the table that already exist? Is this the way it's meant to work and I need to manually edit the Up method to get why I need? Hopefully I can get my head around the way the migrations are designed to work, so that I can work with it and not against it. Thanks Andrew |
|
|
The initial migration always asks to create tables for the entire model. This is because most people want a migration script to be standalone -- otherwise when creating a new database you would have to run your 'old skool' script to get it to the starting point of the migrations, then the migrations to manage the changes from there. After this, when you create a migration, LightSpeed compares the current model to the model as it was at the last migration, and offers to create the required changes. Note that LightSpeed DOESN'T remember what you excluded at the previous migration, and DOESN'T consider the state of your dev database. It just asks itself 'what has changed in the model between then and now?' So what is happening in your scenario is that you are creating an initial migration. LightSpeed doesn't look at what it would take to upgrade your dev database, it looks at what it needs to create your model starting from scratch (because migrations are all about repeatability, and your dev database is not a replicable starting point, whereas an empty database is). So it proposes to create all the tables. However, you tell it, "No, only create the Themes table." So it doesn't try to create the Projects table, and as a result, the ThemeId column is never created. Put another way, LightSpeed doesn't convert the 'create a Projects table' proposal into an 'alter an existing Projects table' action just because you left Theme in but excluded Project. The solution for this is to start out by creating a version of the model that includes the Project entity as it currently exists in your database, and any other existing tables of interest. Then, before making any further changes, create a migration for that, and exclude all the proposed 'create table' operations. This gives you a baseline migration which represents the current state of your database. Now add the Theme entity and the Project association. This time, LightSpeed will know it shouldn't create the Projects table, because that existed in the previous version, but it will spot that it needs to add a column to that table. (Whereas with your current approach, it spotted that the Projects table needed a ThemeId column, but it bundled that up with creating the Projects table, which you told it not to do.) Hopefully that helps. The important part of the mental model is to think about migrations as differences from previous versions of the model, not differences from the database. From this it hopefully makes sense that if you want to capture differences from an existing database, you must first make a version of the model which represents that existing database (and nothing more) -- then your future migrations will be incremental diffs from that version, and will therefore be suitable for applying to that existing database. |
|
|
Hi Ivan, That makes things a lot clearer. I've done what you suggested and taken the model back to before I added the Theme entity. I then created a migration called Baseline and deselected all the checkboxes. Then, without making any changes tot he model, I created a 2nd migration to check that everything was cleared out, but I see that there are a number of foreign keys listed now (all of which already exist in the database). So again I deselected everything and made a migration and then tried creating a 3rd migration but all the foreign keys are still listed. I was hoping to have a completely blank slate before I started making changes but I can's seem to do it. Thanks Andrew |
|
|
Were the associations corresponding to the FKs present in the previous version of the model? It seems like LightSpeed thinks you have created new associations whereas you think you haven't (as I mentioned, LightSpeed doesn't care that you excluded stuff, it is just comparing versions of the model). Could you post the .lsmcheckpoint files corresponding to your Baseline and your second migration please? |
|
|
Wouldn't it make more sense to have two different buttons in the migrations menu? One for "Create BaseLine Migration" with the "Create Migration" button greyed out until someone had done a BaseLine Migration? I didn't even know there was such a thing as a Baseline migration until reading this, I thought it was doing diffs from the server in the Connection String. |
|
|
Hi Ivan, The associations have been in our model for a long time. Files are attached. Thanks Andrew |
|
|
Hi Edward, There isn't such a thing as a baseline migration. I was just using the term informally to refer to creating a migration that brings you up to the level of an existing database schema. Since most migrations users want their migrations to be able to build a database from nothing, this isn't an actual concept in LightSpeed and isn't something we'd want to represent. |
|
|
Hi Andrew, I've found a bug relating to one-to-one associations in migrations which would explain what you're seeing. Could you have a look at the spurious FKs it is trying to create, and let me know, are they all for one-to-one associations, or do you also see them for one-to-many associations? If you do see any for one-to-many associations, can you let me know an example (one should be enough!). Thanks! |
|
|
Hi Ivan, They are all 1:1 associations. Thanks Andrew |
|
|
Excellent! Then there will be a fix in the next nightly build. Thank you for drawing this to our attention -- let us know if you still see problems! |
|
|
Thanks Ivan |
|