I have just started testing migrations in several different team scenarios to make sure migrations will work as expected with git / multiple users / multiple branches. But I have run into an issue right off the bat. On branch 1 I added my Initial migration (on an existing project with 165 entities), deleting the code in Up/Down (just uses the model snapshot), then update-databased (creates the __MigrationHistory table just fine). I merge this to branch 2 (EXACTLY the same model – exact replica of branch 1), ran update-database with my newly merged migrations and it says Unable to update database to match the current model because there are pending changes. There aren’t pending changes, both models are exactly the same. Is there something I am missing here? I thought I should only run into this issue once migrations are out of whack (merge, model changes from different users).
So why must I do add-migration Initial on both branch 1 and branch 2? They are merged and exactly the same.
Notes: EF 5 (technically 4.4) with .NET 4.0. DevArt dotConnect for Oracle v 8.1.55.0
EDIT: I have read this post but I am not on different platforms, I'm on the same computer - just different branches.
I figured it out, in my initial testing of moving off of EDMX to dotConnect code-first + migrations, I added the schema to the _Mapping files for my fluent mappings. I had to remove this schema. Example:
Instead of:
this.ToTable("ADDRESS", "SCHEMA");
I had to use:
this.ToTable("ADDRESS");
Also I use these options in OnModelCreating:
var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.Workarounds.IgnoreDboSchemaName = true;
config.Workarounds.IgnoreSchemaName = true;
Related
I am using asp.net ef core and I have to remove specific migration from the migration folder. How can I do that?
If u wanna delete your last migration after applying it to database use
Remove-Migration -Force
Or if u want to delete any particular migration then use
Remove-Migration "YourMigrationName" -Force
This worked for me.
Note : Be carefull and sure while removing any particular migration cz it might affect your database.
If U Wanna Deleted Your Last Migration You Can Use
Remove-Migration
but if you get this error
**The migration Your Migration Name has already been applied to the database. **
this mean you use Update-Database and your migration add in database so if you wanna delete this migration you should find migration table in you Database and delete from migration table and delete any table you don't need that. and again use
Remove-Database and this will work.
If your data isn't big so you can use this but be careful maybe your data you had save
will delete ....
My Git flow consists of develop, master and feature branches. I use Alembic for database migrations, and I run migrations only after merging branches into master.
Currently, merging a branch containing migrations into develop causes trouble. Here is the problematic process:
New branch off of develop (BRANCH 1)
Create migrations in BRANCH 1
Merge BRANCH 1 into develop
The migrations aren't being run because they are not in master
Another new branch off of develop for a different feature (BRANCH 2)
Now, it's impossible to create migrations in BRANCH 2 - I get Target database is not up to date because the head revision is the new revision created in #1, but the database has not been upgraded yet.
Running alembic history gives:
c4892151a825 -> 3451e691af8a (head), BRANCH 1
c4a0d473218e -> c4892151a825, MASTER MIGRATIONS
What I'm trying to achieve is to have the two migrations run sequentially:
c4892151a825 -> 3451e691a4jf BRANCH 2
c4892151a825 -> 3451e691af8a BRANCH 1
... -> c4892151a825, (head), MASTER MIGRATIONS
I tried running alembic revision --head c4892151a825, but it says that the revision is not a head revision.
I found a temporary solution:
move BRANCH 1 migration file to a different location
Create a new revision.
Return the migration file to the previous location and merge the two using alembic merge.
I am building a application with ASP.NET Core MVC6 and Entity Framework Core code first with build in DB context, the SQL database has already been populated with data records. I recently made some small changes to the data models and recreate the migration, with commands as ("dotnet ef migrations add Stage3", "dotnet ef database update") in VS 2015 Package Manager Console, but it ran into error as:
dotnet.exe : System.Data.SqlClient.SqlException (0x80131904): There is already an object named 'Company' in the database.
Company table is on the top of the tables relationship, it seems that because the table Company is already there and the EF can not update the new table structure. If I change DB name in the connection string, it will create new database with new table structure without any issues. I am not sure how to address this issue? After the application go live in the near future I will properly make more changes to the Modes and will have same issue again and I cannot delete database with live data to recreate new table structure, Maybe I should configure it in the Startup.cs file, but I haven't found any useful resources yet. Please give me some advises.
I have attempted to change the DB Initializer as attached screenshot, but not sure how to do it.
I checked the project code again, the migration has not been applied to __MigrationHistory table, the migration code actually contained the code to create whole database structure as sample below:
migrationBuilder.CreateTable(
name: "Company",
columns: table => new
{
CompanyId = table.Column<int>(nullable: false)
.Annotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn),
CompanyName = table.Column<string>(maxLength: 100, nullable: false),
IsAdmin = table.Column<bool>(nullable: false)
},
constraints: table =>
{
table.PrimaryKey("PK_Company", x => x.CompanyId);
});
And I haven't changed the project namespace. Recently I just made some changes on few table relationships such as site user permission table(company has many sites). I added a permission table, so now site user permission table can have multiple permissions type instead of single permission type.
Not sure how to set up automatic migrations in Entity framework core.
In Entity framework code first approch, there are four different database initialization strategies:
CreateDatabaseIfNotExists: This is default initializer. As the name
suggests, it will create the database if none exists as per the
configuration. However, if you change the model class and then run
the application with this initializer, then it will throw an
exception.
DropCreateDatabaseIfModelChanges: This initializer drops an existing database and creates a new database, if your model classes
(entity classes) have been changed. So you don't have to worry about
maintaining your database schema, when your model classes change.
DropCreateDatabaseAlways: As the name suggests, this initializer drops an existing database every time you run the application,
irrespective of whether your model classes have changed or not. This
will be useful, when you want fresh database, every time you run the
application, like while you are developing the application.
Custom DB Initializer: You can also create your own custom initializer, if any of the above doesn't satisfy your requirements or
you want to do some other process that initializes the database using
the above initializer.
So if you are using DropCreateDatabaseIfModelChanges or DropCreateDatabaseAlways then replace it with CreateDatabaseIfNotExists.
Please try this out.
I have a minor issue which force me to introduce a new migration in between two migrations.
Short version of my question is: whether it is safe to introduce a new migration between previous two.
What I did
I need to have a table which will be filled from a file.
I added a table then imported data on the table by two migrations:
A migration which create a table with named ID column by using self.primary_key = some_id
A migration to import text data onto the table
The issue was, I forgot to add :id => false to the first migration. This cause id column to be created but haven't set correctly. Since I have primary key in some_id it does not cause problem up to now.
Rails 3.2.4
Now, I upgraded to Rails 3.2.4. Due to the change, it look like I need to set unique id before save. Which cause migration 2 above to fail.
The easiest fix is removing id column between above two migrations because I need test suite to build the database from scratch time to time. To make the import to work, I need to fix it before 2nd migration run.
Question
Now the question.
Since above migrations are deployed already, The migration will run after all of the migrations other than the one.
In my case, it looks like Ok to create such a migration (with timestamp in between above two).
Is it okay to do add migration like this way, in this case?
We're developing a Doctrine backed website using YAML to define our schema. Our schema changes regularly (including fk relations) so we need to do a lot of:
Doctrine::generateModelsFromYaml(APPPATH . 'models/yaml', APPPATH . 'models', array('generateTableClasses' => true));
Doctrine::dropDatabases();
Doctrine::createDatabases();
Doctrine::createTablesFromModels();
We would like to keep existing data and store it back in the re-created database. So I copy the data into a temporary database before the main db is dropped.
How do I get the data from the "old-scheme DB copy" to the "new-scheme DB"? (the new scheme only contains NEW columns, NO COLUMNS ARE REMOVED)
NOTE:
This obviously doesn't work because the column count doesn't match.
SELECT * FROM copy.Table INTO newscheme.Table
This obviously does work, however this is consuming too much time to write for every table:
SELECT old.col, old.col2, old.col3,'somenewdefaultvalue' FROM copy.Table as old INTO newscheme.Table
Have you looked into Migrations? They allow you to alter your database schema in programmatical way. WIthout losing data (unless you remove colums, of course)
How about writing a script (using the Doctrine classes for example) which parses the yaml schema files (both the previous version and the "next" version) and generates the sql scripts to run? It would be a one-time job and not require that much work. The benefit of generating manual migration scripts is that you can easily store them in the version control system and replay version steps later on. If that's not something you need, you can just gather up changes in the code and do it directly through the database driver.
Of course, the more fancy your schema changes becomes, the harder the maintenance will get i.e. column name changes, null to not null etc.