While studying and following along with the migration section, I had done the initial, then followed it up with the next two migrations as shown. On the last migration an error of the "course" is already in the database. Exact error "There is already an object named 'Course' in the database." I removed all migrations and re-did the shown migrations, each time ending with the same error.
Why does this type of error occur? A
nd how to completely remove all migrations (my migration folder was blank) so that one can move forward with the next migration. Am I missing something?
This is potentially a big topic to fit into a single answer. I will try to give you an overview, background and advice. Further reading will be required to get a full understanding of how Entity Framework should be utilised. I will mostly cover Migrations, as that is the main thrust of your question.
OVERVIEW
Entity Framework Migrations offer the ability to rollback the changes made to a database, back to the schema of the database that is contained in a specified Migration; e.g. to undo schema changes by returning the database to a previous schema - and also to return it to its original state.
Note that data loss can occur when applying or rolling back Migrations, but in your scenario this is possibly not important.
The command to return a database to a specific Migration is:
Update-Database -TargetMigration:"migration_name"
The command to return to the initial, original state of the database is:
Update-Database –TargetMigration: $InitialDatabase
Entity Framework also has the optional concepts of Database Initialization and Initialization Strategies, that allow a developer to specify that the database should only be created once, or dropped and created each time an application is run, depending if their Code First model has changed. Please refer to these tutorials for more in depth coverage of Database Initialization.
As you say you have no Migration files in your Migrations folder, let us continue...
BACKGROUND
When you first run the Enable-Migrationscommand, it will create a class that is used for managing subsequent application of Migrations.
When you generate your first Migration, by executing, for example:
Add-Migration InitialCreate
This will create an InitialCreate file within your Migrations folder, that contains the initial schema, according to your class model that will be persisted by Entity Framework. The example name InitialCreate is optional and can be anything you wish - it is simply a label that can be referred to later.
Subsequently, when you issue an Add-Migration command, further Migrations are created to apply schema changes related to your classes; they will be added to your Migrations folder, but, not yet applied to the database.
The Migrations can then be applied to your database by issuing the Update-Database command. If executed without parameters, the database schema is updated to the schema defined by the latest Migration.
If you are following the Contoso tutorial correctly, you should have several Migrations, one of which contains the word 'Initial' in its name, as part of the convention.
ADVICE
If you do not see these, it is likely that you have not initialised Migrations, by issuing the command Enable-Migrations.
After executing Update-Database for the first time, verify this also creates a database table named __MigrationHistory - this tracks the schema versions and Migrations that have been applied.
You have possibly applied Migrations in an incorrect order, and it now does not match your class structure, or, is out of sync with the schema tracking within the database.
In your current circumstances, as you are following a tutorial, it is probably best to delete your database, and recreate it following the steps outlined by Microsoft, paying special attention to the output from Enable-Migrations, Add-Migration and Update-Database commands, verifying the database schema at each step.
REFERENCE
For reference, the overview of how Migrations should be utilised, can be found on MSDN here.
A walkthrough of using Migrations with MVC can be found here
Related
I am working with Symfony and Doctrine. In the middle of the project I need to implement the Doctrine migrations, because the DB changes were too much and I need a better way to handle it.
How is the best way to start with the migrations, when there is already data on prod and it need to stay there and not to be touched?
My plan will be:
On my test system
drop all tables
run php bin/console doctrine:migrations:diff
The new automatic migration file, which I become holds all the table structures of my current state
go live to the table "migration_versions" and add the ID of this migration, so it will be skipped by the first run of the
migrations
run the migration php bin/console doctrine:migrations:migrate
In this way, I have all the structures from my entities, but I will not destroy my live data.
What do you thing?
If there is already some data on production, then your best take is to do a make:migration or doc:mig:diff from the current schema state. That will generate only the necessary sql that will update the new changes, but nothing else. Your first migration version will countain only the sql to update from the current state, and not from the beginning of times.
And also, once you have adopted this, you have to do every database modification under migrations. For example, if you need to add a non-nullable field, you usually add the new field with not null, then fill all the rows of that field with a default or calculated one, and then alter the table to make the field not nullable. Migrations will generate some boilerplate code to make your life easier, but it also requires a lot of care from the development team. Always test them first in a database that you can get rid of. And you will run into FK constraints and lots of other issues, but basically you have to solve them doing SQL.
Old thread here, but what I do in cases like this:
Backup dev database (structure and data, but with table create statements protected with checking so they are only created if they don’t already exist)
Drop all tables so the database is empty
Generate migration (since database is empty, the generated migration will constitute all commands necessary to generate your entire schema)
Run migration you just generated to build schema
Import test data from your dump
That puts you right back where you started but with an initial migration that can build your schema from nothing.
I am trying to modify my code first migration so that I can add a new table to the db, called "GunControl." However, when I enter "Add-Migration GunControl" in the package manager, I get the error message:
"Unable to generate an explicit migration because the following explicit migrations are pending: [201705171404346_Questionnaire]. Apply the pending explicit migrations before attempting to generate a new explicit migration."
QuestionnaireDbEntities.mdf is the name of by db, and GunControl inherits from the class Questionnaire. I have looked everywhere online, and I can't find a way to do this. Thank you so much for your time!
This occurs because you have an existing database already that you're connecting to. The database keeps track of what migrations have been applied to it and when you run Add-Migration it compares the database schema with your models and sees that you've created a migration previously (201705171404346_Questionnaire) which has not yet been applied to the actual database. Because of this, the new migration can't determine what has changed in the schema when comparing the database.
Your options are:
Run Update-Database to apply the previous migration.
Delete the migration file 201705171404346_Questionnaire.cs and then run Add-Migration again which will contain both sets of changes.
Delete the entire database and all migration files, then run Add-Migration to create the initial schema.
I am on Entity Framework 6.0. This is a development issue, not Production.
I think I have a conflicting strategy in place.
Currently I have a DropCreateDatabaseIfModelChanges database initializer set and have migrations enabled with a seed method in Configuration.cs.
On adding a migration and running update-database, it seems like a lucky dip as to when the database is dropped and recreated and when the seed method runs.
The fact is, it's a total lottery as to when either happens, and I have to pull all sorts of tricks to get the thing to work.
Can someone tell me if it is conflicting to have both a database initialiser and migrations enabled.
Thanks
That is not a proper combination. There is a MigrateDatabaseToLatestVersion Initializer for use with migrations.
During early development, you may want to use a DropCreateDatabaseIfModelChanges initializer (or CreateDatabaseIfNotExists). There is a special Seed() method for initializers that only runs when the database is created.
Once you reach a point where what's in the database is a pain to reseed you can switch to migrations. Change your initializer and enable migrations. Be sure to add an initial baseline migration (add-migration Initial -IgnoreChanges) so you will only get the changes after that point. You can now add migration Seeding that runs every time you update-database as opposed to the initializer Seed that only runs if the database is created.
If you need to recreate the database, you can generate an idempotent script that will create the database and apply all migrations.
I am working with doctrine:migrations:diff in order to prepare database evolutions.
This command creates files into app/DoctrineMigrations
Thoses files contains sql commands in order to upgrade or downgrade database scructure.
I want to store those sql commands into the database itself. In fact, i have several instances of databases. If sql commands are store into files, it is a big problem.
I have read somewhere that DoctrineMigrations bundle can create a table called "migration_versions", but i do not manage to find where i have read this...
I cannot really understand what you're trying to do.
Migrations are used when your code needs altered database structure. For example, a new table or a new column. These new requirements for a table or column comes from your newly written code, so it's only natural to place the migrations also as a code in your repository.
How and when would migrations even get to your database? How would you guarantee that migration is executed before the code changes, which use that new structure?
Generally, migrations are used in this way:
You develop your code, add new features, change existing ones. Your code needs changes to database.
You generate doctrine migration class, which contains needed SQL statements for your current database to get to the needed state.
You alter the class adding any more required SQL statements. For example, UPDATE statements to migrate your data, not only the structure.
You execute migration locally.
You test your code with database changes. If you need more changes, you either add new migration, or execute migration down, delete it and regenerate it. Never change the migration class, as you'll loose what's supposed to be in the database and what's not.
You commit your migration together with code that uses it.
Then comes the deployment part:
- For each server, upload the code, clear and warm-up cache, run other installation scripts. Then run migrations. And only then switch to the new code.
This way your database is always in-sync with current code in the server that uses that database.
migration_versions database table is created automatically by doctrine migrations. It holds only the version numbers of migration classes - it's used for keeping track which migrations were already run and which was not.
This way when you run doctrine:migrations:migrate all not-yet-ran migrations are executed. This allows to migrate few commits at once, have several migrations in a commit etc.
I've created a project using EF code first but am stuck with the application unable to initialize (unless I enable automatic migrations which I don't want). This isn't a production system, but I'm trying to learn how to use code-first (and am struggling).
I've previously been through the steps to enable code first migrations, I have a configuration class with a seed method, and my project has worked previously.
I started getting an error:
"Unable to update database to match the current model because there
are pending changes and automatic migration is disabled"
So I've done the following:
Dropped the database completely, and created an empty one.
Deleted all existing DbMigration classes in the project
Created a new DbMigration class called 'InitialState' with the 'add-migration' command.
Run the 'update-database' command
The database update runs successfully, the seed method runs successfully and I can see the tables and data in my database. There is one row in the migration history table for my one migration 'InitialState'. It all looks fine, but when I run up the application, still get the same initial error. If I run the 'add-migration' and 'update-database' commands again, it creates a blank migration and updates, but I still get the error.
If I enable automatic migrations, an auto-migration entry appears in the migrations table and my app runs. But I don't want automatic migrations.