I am trying to deploy an EF 4.1 Code-First application from Dev to Test without letting EF "blow-away" the entire database.
I copy the database over from Dev to Test, rebuilt the application and deploy the code. For EF still thinks it needs to rebuild the DB or that the data models are different. How can I predict which ModelHash the application will want to see when it is deployed to a different server?
As far as I can tell, the only difference between the two builds is the configuration I use to build them (one is Test, and the other Dev).
If you want someone else to use your DB and now have to Re Create it each time.
I set my DB Initializer = CreateDatabaseIfNotExists
Then delete the "EdmMetadata" table from the DB.
I am not sure if this is the "correct" way to do it. But it works for me.
System.Data.Entity.Infrastructure.EdmMetadata.TryGetModelHash(DbContext)
will return you hash string of the model.
That's what the EF want to see in ModelHash column at EdmMetadata table.
Related
Inside of OnModelCreating, I want to be able to ignore a column if the database is on an older migration EF Core 5 throws an exception if I attempt to read from the database directly, or indirectly by querying the applied migrations. I'm not certian that it's even a good idea, since OnModelCreating is used during the migration 😩, but I'll burn that bridge when I cross it.
There are some examples on how one would do this with EF6, but they don't seem to apply anymore with EF Core.
While Ivan Stoev is right that --generally-- you should model the target database without outside input, the real world isn't always that clear-cut. In my particular case, there are multiple service instances (Azure Functions) that need to read and write to a single database. In order to maintain zero downtime, those Functions need to not read or write columns that don't yet exist.
I solved the problem the way Serge suggested. The database has a known version, populated with seed data that increments with every migration. On startup, the service reads that version with a regular old Microsoft.Data.Sql.SqlConnection. This version is then added to the IServiceCollection as a singleton to be used by the DbContext constructor.
When talking to an older database version, OnModelCreating does things like this:
builder.Entity<Widget>(w =>
{
// another option would be to use the migrations table instead of an integer
if (DatabaseVersion < ContextVersions.WidgetNewPropertyAddedVersion)
{
w.Ignore(w => w.NewProperty);
}
else
{
w.Property(w => w.NewProperty)
.HasDefaultValue(0);
}
});
The startup code also detects if it's been started by the Entity Framework tools and does not read the database version, instead assuming "latest". This way, we do not ignore new properties when building the migration.
Figuring out how to let the service instances know that the database has been upgraded and they should restart to get the new database model is an exercise left up to the reader. :)
I am a newbie in Codefirst and I do not understand how it works correctly.
I created 3 migrations, migration 1..3 via "Add-Migration" command and issued the relative update with "Update Database".
I have a Configuration.cs file in my Migration directory and custom database initializer (I am working on MySQL) I created in order to seed initial data.
I do not know what happens behind the scenes in the production environment where I do not have any database yet.
Who is responsible to create and update the database? Are the migrations executed one after the other?
Can you suggest me how this process works in production and share useful links?
Regards,
Roberto
Assuming you are using Automatic Migrations - All migrations are called one after another, in the sequence in which they were created. Their Up function is called. Afterwards the Seed function on your Configuration class should fire.
Each migration has a sort of a Time-Stamp inside its file name, like this:
if you are creating lots of databases out of a single context class like I do, and you are afraid of not having control over migrations, you can use manual migrations. It is called DbMigrator.
See my/others answer here how to use it.
Desired outcome:
Use model first approach with Entity Framework and allow changes to deployed database/ model to be done automatically based on the changes in the model. Automatic schema difference script generation to allow smooth migrations.
Is there a way to perform migrations in model first EF6? I can see code first migrations topics all over, but nothing much on Model First.
Options I saw so far:
Database generation power pack (seems outdated)
somehow convert to code first, then use migrations (not desirable, as I like to have a visual designer)
somehow piggy back on code first migrations (http://blog.amusedia.com/2012/08/entity-framework-migration-with-model.html : this is for EF5, got error that can't run migrations on Model First)
some third party tools?
As far as I know there still is no automatic migration for Entity framework model first.
Our approach is:
Create a fresh database from the model.
Create a diff script to migrate the old database to the new one.
Verify that this diff script is indeed correct. Always double check what your automation tool creates.
We first used Open DB diff for our model first migrations. After that we switched to Redgate's SQL compare because it produced more reliable migrations .
In our experience DbDiff produced a lot of unnecessary SQL because it bothers with the order that columns are in, and has some other issues like foreign keys constantly being dropped and re-added. Aside from that it still did the job fine, but we had to do a lot of double checking on its generated SQL.
I am stuck trying to figure out how to set the database to run a migration on.
I have created a new empty project and set up Entity Framework using code first. I have all my classes built.
I want to add a new database and run the migrations on this. I have Migrations working but I can't figure out what database they are running on.
Is it possible to set the database you want to use for the migrations?
Multiple DBs for the same context gets a little tricky. But It is possible:
The essence of the problem is how EF decides which connection to use.
It will access instantiate the context without NO PARAMS during migration.
So depending on how that behaves influences you outcome and success.
Start here:
EntityFramework code-first custom connection string and migrations
I am developing an EF - MVC 3 application. I have used model first approach, so I have create model first and from that model, EF generated the DB.
I have used a tool called Nuget - Entity Generator - Database designer for generating the database. When I have designed the model first time, I have used the Generate Migration T-SQL and Deploy option of that tool.
Database generated perfectly and it's working fine...
Now I have come across a situation that I have to make a change to the model and I have to use T-SQL Via T4 (TPH) option to update the database.
So previously I used different process to update DB and now I am changing it.
When I use the T-SQL Via T4 (TPH) all the tables get deleted and new tables get created.
How to avoid this ?
I want to only update the table which I have made the changes.
Entity framework 4.3 comes with migration support. This is not available in EF 4.1.
Some links from google:
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx