After restoring a database from 1 server to another, I get an AutomaticMigrationsDisabledException from EF saying that the database does match the current model although they actually do match.
So I try to generate a migration from VS and it only contains a bunch of CreateIndex statements for which there already are indexes in the database. And sure enough, when I execute the migration, I get an error.
I previously restored the exact same database to yet another server without any problems. However, the servers are not completely identical. They are all SQL Server 2008, but some have different combinations of SP and KB applied to them.
I'm using EF 6.1.
Can you figure out what the problem is?
It is a bug in version 6.1, will be fixed in 6.1.1 - https://entityframework.codeplex.com/workitem/2167
Related
we're running EntityFramework (6.1.3) Code-First with about 40 migrations on a small database (490 MB) on SQL Azure.
While extending our release process with a check to call Database.CompatibleWithModel to verify if the database is up to date, I've found that our test instance got rather slow: this call will take up to 2 minutes to complete. On our production environment and locally this is less than a second!
I've run a SQL profiler job locally and found only 3 statements that get fired on the the database:
Does the database exist?
How many migrations are in the database?
What is the migrationId and model of the last migration?
When I run these statements on the slow environment it completes within a second, just like on production. This indicates that the database is not an issue.
Does anyone have an idea were to search for the reason of the slow performance? Does EF calculate the hash locally on runtime and then checks that against the model in the database?
Can I find out how long it takes to hash?
I've checked the settings on the Azure Database to check against the CompatibilityLevel of the database, after finding a post that the EDMX editor is slow with the new cardinality estimator, but this setting seems to have no effect.
I have been updating my entities in development and that resulted in several migrations and update database commands, to a particular database.
What happens if I change the connection string (because the new database sits on a later version of SQL Server, for example) and then run the database update again? I have the impression that EF would detect the new database, run through all of my migrations, and produce one script and execute so that my new database has all the tables, columns, and relationships exactly as how the last migration left it. Can I just change the connection string and I'll get the new database as expected?
Many tell me that I have to create a separate deployment project for each database I want to manipulate with EF, but that seems rather tedious.
If there are different Tables and Columns it will bomb out right away with an Exception on the mismatched column/table name, if your databases are the exact same (and at the same Migration History), it should update it.
If you have two Databases that are not on the same migration history, you can run
Update-Database -TargetMigration migrationName
And this will effectively revert a Migration, just be sure to delete the migration that was added to the solution directory. (This sometimes happens when switching between branches / databases a lot, and may save you some time)
"Can I just change the connection string and I'll get the new database as expected?"
As long as the Migration History isn't mismatched and the Connection String is Pointing to the right place.
"Many tell me that I have to create a separate deployment project for each database I want to manipulate with EF"
If you are using Visual Studio, you can create different publishing profiles if needed
I am using EF 6 code first. As part of the code-based migration, I would like to rename the existing database after applying all the pending migrations. Can this be done?
I don't think this would be (easily?) possible (without causing errors)
If you rename the database during the migration it wont be able to write the migration out to the migrationhistory table as the connection string will still be pointing to the old database.
Perhaps a better option would be to build something into the system to rename the database and adjust the required configuration outside of EF entirely.
I am working on a system that currently has a number of environments (test, stage, live, etc) each with their own database. So far these databases have been kept in sync by running the same update scripts on each of them.
We are now moving to using EF6 code first migrations, and would also like to start writing some automated system tests using LocalDB.
I've found https://msdn.microsoft.com/pt-pt/data/dn579398 which describes two options for adding an initial migration.
The first method creates an empty initial migration which will work great for the existing environments but won't help with creating LocalDBs for testing.
The second method creates a migration to bring up the whole database from scratch (minus things EF doesn't care about such as sprocs and views). This would be acceptable for testing, but not good for actually recreating a databse. It also requires you to manually comment out the Up method, run the migration on all existing databases, and then put the Up method back. As it will take a while to get the migration through all the environments I'm not keen on this. It also violates the one of the principles of migrations which is that they shouldn't be edited once they've been released.
Having some kind of conditionality in migrations would solve my problem (e.g. if(tableExists("A_table_in_the_existing_database") return;) but there doesn't seem to be anything like that available.
The best I've come up with is to dump the existing database schema from SQL server to a file (which has the advantage of preserving sprocs, views, etc) and then use option 2 above, except instead of using the generated Up method I'll run the SQL file.
However, this still has the drawbacks of option 2 mentioned above, so I'd be very happy to learn of a better way of handling this situation.
Edit:
Would this work? Run the commented out initial migration on one database, then dumping out the __MigrationHistory table and inserting it into the other databases? That way I wouldn't have to wait for the migration to make it through all the environments before I could safely uncomment it.
EF 6.1.2 has support for running SQL embedded as a resource within the assembly containing the migrations using the SqlResource method.
I think I'd go with scripting out your existing schema and using an initial migration that executes SqlResource as its Up. If all it's doing is a bunch of IF EXISTS then it shouldn't take too long to run. Otherwise scripting out __MigrationHistory will also work if you just want to run it once locally and apply to all your other databases by hand.
I've started looking into Entity Framework migrations on 4.3.1. Have a few questions:
What's preferred during development? Why should I not just drop and recreate my
database always and then reseed. If I use code first migrations, can
I choose to seed my db initially and then add a seed method to each
migration to only add in new data? If i use automatic migrations, is
it possible to do something similar? i.e. seed initially and then
seed as required?
What is the benefit of using migrations during development? I only
actually need migrations when moving to production. So, I need to
create my initial script and then scripts for each migration, so
would it be possible to only use migrations once i want to move to
production and at that point create an initial script and maintain a
migration history from that point onwards?
Well, in our case, we started to use Migrations because in our company, devs don't have the necessary rights to create a DB, which lead to the amusing scenario where I dropped the DB a couple of times and had to ask the db admin to recreate it each time...
In my opinion, it seems easier to incrementally grow your DB, rather than having to recreate it each time. If I were to have to drop and recreate our DB every time a property is added, deleted or changed, I'd never see the end of it.
I've not yet seen a possibility for incremental seeds, unless perhaps if you create manual migration files.
Migrations has the possibility to go to a specific version (either forwards or backwards) and it is possible to generate an SQL script from a migration.
So basically, you don't have to create a migration SQL script by hand anymore, you can get Migrations to do it for you.