4

The EF migrations seem cool but there is too much "magic" going on and very few explanations as to what it's actually doing. All I want to do is set migration points and get DDL scripts -- either a "diff" script from one migration to another or the entire create DDL script.

The problem is that all the migration commands seem dependent on an actual database being present to perform a bunch of stuff I'm not interested in. Is there a way to bypass all that and just work with migrations to generate scripts?

w.brian
  • 16,296
  • 14
  • 69
  • 118
  • I totally agree with you about the Migrations (over)design. The whole concept works much better in a team environment if I can do every step except Update-Database without a database. – Scott Stafford May 30 '12 at 15:07

1 Answers1

0

This was discussed yesterday. Migrations commands are dependent on your working database because they interact with __MigrationHistory table to get actual state and to correctly compute what changes have to be done.

If you just need to create scripts you can do that by using Update-Database with additional parameters:

Create script for whole database:

Update-Database -Script -SourceMigration:$InitialDatabase

Create script for upgrading from migration A to migration B:

Update-Database -Script -SourceMigration:"A" -TargetMigration:"B"
Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Unfortunately, I'm unable to run the second example because creating a second migration fails, saying that I have explicit migrations pending. Very frustrating really, there should be an option to opt-out of the "magic" they are trying to perform. – w.brian May 31 '12 at 15:41
  • I didn't say that it will work without database. Database is core requirement for current version of migrations. You can never have more than one migration which wasn't applied to your database. If you don't like it you should rather handle database upgrades yourselves - for example with VS Database project. – Ladislav Mrnka May 31 '12 at 16:47
  • Obviously it depends on the database, my point is that it's entirely unnecessary if I'm explicitly setting migration points and specifying migration points to script from. Simply telling me not to use it is both obvious and a bit snarky considering it doesn't meet my requirements. – w.brian May 31 '12 at 17:35
  • EF simply uses database centric approach to avoid accidental damage to database. The reason is IMHO existence of automatic migrations because your code doesn't contain information about the existence of applied automatic migration until it queries the database. The fact that you have at the moment `AutomaticMigrationEnabled` set to false is not enough because you could just change it few minutes ago. This way the behavior is more deterministic and secure. Anyway you can propose change on [Data UserVoice](http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions). – Ladislav Mrnka May 31 '12 at 17:56
  • This is really not a good excuse not to have the ability to override this behaviour. Does it really make sense that we hand-roll our own Migrations just because we can't explicitly opt-out of this validation? There should be a switch that lets us that know what we're doing opt-out! :( http://stackoverflow.com/questions/11204900/how-can-i-stop-add-migration-checking-my-database-has-no-pending-migrations-when – Danny Tuppeny Jun 26 '12 at 10:18