2

We're working with EF Migrations in one project with 3 states:

  • Development: every developer has its own database
  • Staging: same database as production
  • Production: same database as staging

We have no problem in Development: we have changed our DbContext and EF migrations changes our database. Every developer has the correct code an de correct database.

The problem comes when we upload the project to staging. We need to update the staging database because of

The model backing the 'XXX' context has changed since the database was created

But if we update the database (using migrations), Production throws the same message (because Production and Staging has the same database).

The database changes are minimal, so it would be no problem if we didn't use EF migrations.

Any advice?

Improve this question

2 Answers 2

Reset to default
2

I know this has been answered already - but just to add for 'historical purposes' and others that may be seeing this...

The scenario that you have - supporting both Production and Staging backed with the same database - is a bit problematic from the Migrations standpoint.

You can do away with migrations - drop the migrations table (the __MigrationHistory) - and synchronize things (see below posts for more) - but having two code-bases pointing to same Db means one migration table - and unless the codes are the same (migration-wise) it won't work. So the only solution would be to turn off migrations.

However, there seems to be a light at the end of the tunnel.

New builds coming from EF (EF6 pre-releases) have the Code First Migrations History Table Customization.

I haven't managed time to play with that yet, but...
What that means is - simply put you can customize your Configuration and override the IHistoryContextFactory. That in turn allows you to rename the migration table.

For more complex scenarios - like you have - that could be a solution

note that it's not confirmed - but I'm thinking that they put it in there for those very reasons.

A 'pseudo solution' would look like this...

  • make two factories - for staging and production - each creates different 'migration table',
  • each deployment - has its own migrations (in code) - and migration history in the database,
  • you can manually tweak specific 'migration table' for e.g. staging - if needed - w/o compromising the other,
  • make sure your database is 'similar enough' so that both codes/migrations can run side-by-side

That could work, I think...

How to Synchronize Db / Code - Summary
How to Synchronize Db / Code - Long Version

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Seems extremly interesting!! Thanks ;)
1

Maybe is your design problem to use the same Database in Staggig and in Production.

But

The database changes are minimal

is already not the same database. Sure you cannot calculate the same hash value even after small changes =)

I think this is the way it should work.

We also have some kind of development database for every developer local, test database - for test purposes and productivity database.

And all the three are different Instances.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.