I want to do code first development on an existing SQL Server Database. I have used the Scaffold-DbContext command to generate the entities that I want into the tables I want. That's great. But, there were previously code first migrations done to this database. So I deleted the __EFMigrationsHistory table in the SQL Database. Now I want to start doing migrations. Unfortunately, when I run Add-Migration, it generates migration code to generate all of the tables again. I don't understand how I am supposed to tell it that these tables already exist. When I am reverse engineering, how do I generate the migration of the stuff it's scaffolding for me in the existing database?
Code First Migrations uses a snapshot of the model stored in the most recent migration to detect changes to the model (you can find detailed information about this in Code First Migrations in Team Environments).
Source here.
Run Add-Migration InitialCreate –IgnoreChanges to create the initial migration from an existing database. Then update-database to simply add the migration to the _EFMigrationsHistory table.
After that, you are good to go brother.
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 am using entity framework code first migrations. Very first time I do not have migrations enabled. When I run the project it creates _migrationhistory table with one row in it.
Then I delete this table and ran application, it ran successfully. Now I add one more property to entity and try to run but it did not run complaining that model is not compatible with database.
My question is how EF and database knows model is changed or database is different than model without _migrationhistory table or migrations in code?
Entity framework first checks if the database has _migration history table. If it doesn't have one, it tries to create one and run all the migrations from the beginning and also inserts the migrations name as a record in the migration history table.
Because, you have deleted the migration history table, entity framework cannot compare its migration records with the migration files. Therefore, it tries to run all the migrations again. But, this database already has the table for the relevant entities. Therefore, an error message (model is not compatible with the database) is displayed to the user.
I am in a situation where we have been using (code first) EF migrations against a database that is used as the backing store for two applications. Over the past year or so, we have successfully made DB changes via migrations.
However, at some point a few tables seem to have been manually added and we are now experiencing FK reference errors when we try to delete.
I have attempted the obvious, with the obvious result: Adding the models and generating a migration is going to attempt to recreate the tables in the database.
Is there a strategy to add these new tables to our data model and get our migrations up to date?
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'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.