I am using Entity Framework 5 RC, code first. I am struggling with migrating databases that were created on different versions of code. For example, Database A was created when table FooBar didn't exist. Database B was created after table FooBar was added to my model.
I have a migration written that adds the FooBar table. Is it my responsibility to check in the FooBar migration that the table doesn't exist before calling CreateTable? It seems that is the case since Database B doesn't have an entry for the FooBar migration and will attempt to run it.
At first the MigrationHistory table seemed like it would save me from adding these checks but since new databases won't have entries for migrations added before the database was created, I still need to do the checks myself. Is that the right way to go about it or am I missing something?
To get around an issue I had with adding Stored Procedures, I wrote a TSQL script to create a new table "_PreviousMigrationHistory" - which receives new entries from the "_MigrationHistory" table after my stored procedure scripts have run...
I did add a new column to both tables ( "VersionId", of INT - IDENTITY(1,1) ) which is what I use for comparison within my code.
This way you have the un-updated migration patterns available to you (__PreviousMigrationHistory), even after Code First Migrations have occurred.
Would this help?
**EDIT - sorry, I miss read the question. - Although I would think that new instances of the database would still go through the migration steps, which in turn should add the entries to the __MigrationHistory table?
Related
I am working on a new application in .Net 5 using EF Core. After creating some entity classes and doing the first few migrations I discovered that I wanted to change the data type of column and make it the key in one of the tables. I was able to do that without issue and the app works just fine with that change - but now if I try to change anything else in that table like add a new column and do a migration I get the following error: "To change the IDENTITY property of a column, the column needs to be dropped and recreated." I have tried even dropping the entire table - but nothing seems to work.
Whenever your migrations get messed up, especially early in a project, just delete the migrations folder, drop the Migration History table and start fresh with a new initial migration.
I am using Flask-Migrate==2.0.0. Its not detecting the changes correctly. Every time I run python manage db migrate it generates a script for all models although they have been added successfully in previous revisions. I have added two new columns to a table, migration revision is supposed to have only those two new columns instead all tables are added to it. Is there anything I am missing?
EDIT 1
Here is whats happening.
I added Flask_Migrate to my project.
python manage db init
python manage db migrate
python manage db upgrade
Flask-Migrate generated tables for models plus alembic_version table with having revision
985efbf37786
After this I made some changes. I added two new columns in one of my table and run the command again
python manage db migrate
It generated new revision
934ba2ddbd44
but instead of adding just only those two new columns, the revision contains script for all tables plus those two new columns. So for instance in my first revision, I have something like this
op.create_table('forex_costs',
sa.Column('code', sa.String(), nullable=False),
sa.Column('country', sa.String(), nullable=False),
sa.Column('rate', sa.Numeric(), nullable=False),
sa.PrimaryKeyConstraint('code', 'country', name='forex_costs_id'),
schema='regis'
)
The second revision also contains exactly the same code. I don't understand why if its already generated.
I googled it a little and my problems looks exactly like this https://github.com/miguelgrinberg/Flask-Migrate/issues/93 but I am not using oracle DB. I am using Postgresql. Also I don't know if it has any effect but I am not creating my tables in Default Public Schema, instead I am creating two new schemas (schema_a and schema_b) as I have a lot of tables(Around 100). So just to arrange them.
EDIT 2
The first problem seems to have resolved by adding
include_schemas=True
in env.py.
Now the new migration is not trying to create already existing tables again but it has some issues with foreign keys. Every time I create a new revision, it tries to remove the already existing foreign keys and then tries to add them. Logs looks like this
INFO [alembic.autogenerate.compare] Detected removed foreign key (post_id)(post_id) on table album_photos
INFO [alembic.autogenerate.compare] Detected removed foreign key (album_id)(album_id) on table album_photos
INFO [alembic.autogenerate.compare] Detected removed foreign key (user_id)(user_id) on table album_photos
INFO [alembic.autogenerate.compare] Detected added foreign key (album_id)(album_id) on table prodcat.album_photos
INFO [alembic.autogenerate.compare] Detected added foreign key (post_id)(post_id) on table prodcat.album_photos
INFO [alembic.autogenerate.compare] Detected added foreign key (user_id)(user_id) on table prodcat.album_photos
I have tried adding name to each Foreign Key constraint but that doesn't have any effect.
Thanks for coming back and providing your feedback after you solved the issue. I had grief with the same issue for 2 hours while using postgres
Btw, I would like to point out that you would have to include the include_schemas option in the block context.configure, like so:
context.configure(connection=connection,
target_metadata=target_metadata,
include_schemas=True,
process_revision_directives=process_revision_directives,
**current_app.extensions['migrate'].configure_args)
Setting search_path to public fixed this issue. I always thought that in addition to setting schema info explicitly on each model, we also need to add those schemas on search_path. I was wrong. Changing postgresql search_path is not necessary once schemas are defined explicitly on each model.
The search path means that reflected foreign key definitions will not
match what you have in your model. This only applies to foreign keys
because that's how Postgresql does it. Read through
http://docs.sqlalchemy.org/en/latest/dialects/postgresql.html#remote-schema-table-introspection-and-postgresql-search-path
for background. - Michael Bayer
Recently i upgraded from EF5 to EF6 and here is list of items which one needs to take care of
EF MiniProfiling: if you were using mini profiling with EF5 you will have broken code as few of the functiionality or variable names had been changed.
Resolution: Upgrade to newer version of EF MiniProfiling
Db-Reindexing: After updating to EF6 it complaints you about change in your model and when you do "Add-Migration" you will see all your index for primary key were getting recreated also its changing name of tables where you have one to one relationship so previously if it generates table name as TableATableB then it will rename table as TableBTableA dont know why.
Resolution 1: Let EF create migrations for create index , just comment out line in
up and down function.
Resolution 2: Copy line of code from down function(i.e. drop index) and try to execute it before it create index , simple rule first drop and then create, you need this else EF will complaint about index already present.
Migrations: This will only affect you if you are doing using some tool to deploy you assemblies and which in turns uses migrate.exe typically found at
...#your project location\packages\EntityFramework.6.1.0\tools\migrate.exe
copy it to your bin folder and things should work fine.
4. Null Handling: In EF6 handling of null values had been changed , my hands on experience says that with ef5 select query was ignoring null cases but is not the case with ef6
e.g. if i have query something like
db.context.entity.where(name != "ab");
and lets say entity table contains two names {"ab",null}
with EF5 it will return 1 row with ef6 it was returning 2 rows
http://entityframework.codeplex.com/workitem/2115
Resolution: If you wanted to work exactly like EF5 you can set
dbContext.Configuration.UseDatabaseNullSemantics = true;
If it helps please don't forgot to mark this post as answered :)
I created POCO classes and then EF created the database tables for me when I tried to access the data. This worked without problem. I have now populated my tables with data. Not just seed data but real data.
Now I would like to add another column to a table. I assume the first thing I need to do is to add a field to the POCO class but what's next after that? I now have my database filled with data. On the SQL side I know how to add the column myself but do I have to do something with EF or will it automatically pick up that my column was added to the table and my field to the POCO class?
You can use Code First Migrations (http://msdn.microsoft.com/en-us/library/hh770484(v=vs.103).aspx). It can update your database automatically or not.
Now i'm using EF6 Alpha, and when using migration, it will add a new migration log into the __MigrationHistory table.
In EF6, The __MigrationHistory table has a new column called "ContextKey". After testing, I found there are two default "ContextKey" value:
The full name of DbContext's derived class.This happens when i run the code:
Database.CreateIfNotExists();
The full name of DbMigrationsConfiguration's derived class. This happens when i run the code:
public ArticleDbContext()
{
Database.SetInitializer(new MigrateDatabaseToLatestVersion<ArticleDbContext, ArticleConfiguration>());
}
The first time i run the application, "Database.CreateIfNotExists();" create a new database for me, also all tables that map to the models defined in ArticleDbContext, and then add a __MigrationHistory row which ContextKey's value is "Module.Article.Model.ArticleDbContext".
And then "Database.SetInitializer(new MigrateDatabaseToLatestVersion());" will be runned, this code will generate a new ContextKey "PowerEasy.Module.Article.Migrations.ArticleConfiguration". Migration query the __MigrationHistory table with this ContextKey and find out there's no data. So again it will create all tables that map to the models defined in ArticleDbContext, but the tables are already exist in the database, so an exception will be throwed, and tell me "the table XXX is already existed".
How can i solve this?
You should not mix Migrations and the Database.CreateIfNotExists method (or any of the initializers built on top of it). Migrations will take care of creating the database if it does not already exist.
As an alternative to the Migrations initializer, you can also apply migrations using the DbMigrator.Update method. This is useful if you want to create/update the database before it would otherwise be triggered by the initializer.