is there a plan to do migration in Model first or Database first approach ?

Topics: EF Runtime, General
Sep 27, 2013 at 12:49 PM
hi is there away to use migration in Model first or Database first approach ?
and if not , is there a plan to do one

thanks
Developer
Sep 27, 2013 at 4:59 PM
Unfortunately at the moment it is not possible to use migrations with model/database first. We thought about adding this feature in the future but at the moment we don't have any definite timeline for doing this.
Nov 30, 2013 at 5:32 PM
I'd like to +1 this request. For some applications (and for some teams) Model First is very common -- supporting a migration plan for this use case really should be part of the core framework...
Dec 8, 2013 at 3:20 PM
I am close to "-1" on that. Seriously. There are those of us for whom any form of migration etc. is not wanted. Not "not needed" but seirously counterproductive. In fact, the way EF implements any form of migration is really not - something I want at all. As in: Actively not want.

Problems:
  • A software should not never ever modify the database. THis can lead to all kinds of issues. A versioning mechanism is nice, but normal software should just "stop with an error" if the database is old.
Database migrations are part of maintenance - and should be done by a DBA after taking a backup. Right now the problem is that if you version up and someone starts a new database version, the database migrates - that is nice on paper, but in a larger setup it means one user using a not approoved newer version of the software migrates the database. JIKES.

Also, sometimes that is not possible at hoc. There are scenarios where database migration must be planned. As in: done during a maintenance window. Adding a field to a 8 billion row table takes time.
  • It is feature anemic. It always will be.
Anyone ever seen more complex databases realizes how many features one misses on the database side. Stuff like partitioning, compression etc. are not something an ORM should care about and are things that can not nicely be put down in a standardized way in an ORM. Anyont thinking SQL syntax differences between databases are hard should try really using sql server or oracle specific design features. Welcome in hell. THose features are needed, though, but it means any abstract presentation will just not work.

A simple example? Here we go.

You plan adding an Index mapping to Entity Framework. NICE. WIll work MOST of the time. BUt what about those cases where additional fields are in an index (included columns) for standard queries to be faster. Or a filtered index that does not cover the whole table? BOTH are scnearios I regularly use.

THe ONLY way I see to work with databases are build and migration scripts. That are then applied from an admin app (powershell cmdlet). That then run all your migrations step by step....


The app checks the registered database version on start and throws an errror.

But any migration I have seen in EF so far was only ever usefull for small stuff ("hello world level example") and not usable in larger / complex database scenarios.

The less work is done on that stuff the better. Not when EF has serious holes in base functionality (stored procedures, sensible mapping of enums).
Jan 29 at 11:08 PM
I generally agree with you, but not entirely.

During development, when the database is being revved 20 times a day, having a structured "apply changes" mechanism would be very useful.

Your comments are valid for production environments; but even there, I would love to have an online sql "diff" tool that would prepare an upgrade script to "apply changes".

Biggest issue I have is when dev environment is seriously out of sync with production environment, or (in my case) where the N different production environments I have running are out of sync with each other let alone the dev environment. View dependencies can only go so far.
Feb 3 at 8:01 AM
I hate to tell you - that is a non-Argument.

First, deployment scripts as main measure of Change are something that can be executed from the program, too.

Second, database rebuilds can be autoamted, too.

Want to know the alternative?

Microsoft Database Projects in Visual Studio. Same functionality for simple migrations. Scripts with updates for production. I use a Change script repository and a powershell cmdlet to update the database. Can be automatically called from the application, too, during development.

The diff tool will not work. Really. I often to migrations in phases because they can not be done in one run. YOu again are on degenerate cases.

Example:

A table (Node) has a field "User" that is varchar. Legacy.

THe new Setup has a table "Users" and a field "UserRef" in the node table.

A diff tool will never do that right. A Migration script will:
  • Create the users table.
  • Insert all users it finds in various tables.
  • Add the UserRef field to those tables and populate it with the ID of the user.
  • THEN delete the user field.
This is a simple Change we have like weekly. And one a diff tool already can not do.

We Keep the master copy of the Schema in a SQL Project in Visual Studio - so a new database can be deployed automatically easily. We Keep the Delta sciripts in a Project so a run updates the database with the written Deltas. Best of both worlds without wasting time on migrations in EF that simply DO NOT WORK.