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