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.
- 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).