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.
Related
Running typeorm migrations always creates the migrations and typeorm_metadata table. These tables keep track of migrations done for the particular schema. But, I'd like to execute some ddl commands with this migration facility. Is there a way to not generate them for a migration ?
Doesn't seem to be a logical way to do that, but, the way I got around this is by using the migrationsTableName, I changed it dynamically everytime using a word generator, so the net effect would be as if there was no migrations metadata at all. ;-)
I have a project that has a db first approach initially. However, I have difficulty managing to deployment it to the customers. Because it needs some db updates and I do this manually.
Is there any solution to turn over my DB first approach to the code first approach?
My project is developed in .net core and c# language and also my database firstly Oracle and also Postgre.
Thanks in advance.
You could probably:
create ordinary model classes out of the generated model classes
delete everything else related to the DbFirst approach
Create a code first migration based on the model classes mentioned above
Manually insert a row to the __efmigrationshistory table (in every database you use) with the name of you migration created above --> that way the first generated migration won't run again, as it shouldn't because your db schema is already created
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.