-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Two-stage migrations (compatibility/staging mode) #8932
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
@AndriySvyryd Can you add a bit more explanation, like what we did in triage. |
It's currently possible to do it manually by carefully planning out the changes. As the first improvement we could make this easier by adding a flag to validate that the new migration has no breaking changes. |
Possibly covered by dotnet/EntityFramework.Docs#691 |
We discussed this again and decided that, beyond guidance (possibly a case study) there is nothing we're going to do here. |
Also, per triage, pinging @divega |
Add a way of generating separate scripts for just the non-breaking changes and for the breaking changes. This would allow the previous version of the application to continue to work against the database while the new version is being deployed/tested.
The pattern is sometimes called “Expand/Contract Migrations” because it groups migrations into two categories: Those that are non-destructive expansions of the DB schema and those that are destructive contractions of the schema.
The text was updated successfully, but these errors were encountered: