-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fully embrace provider-specific migrations #16406
Labels
area-migrations
breaking-change
consider-for-next-release
punted-for-6.0
punted-for-7.0
Originally planned for the EF Core 7.0 (EF7) release, but moved out due to resource constraints.
type-enhancement
Milestone
Comments
Notes from triage:
|
23 tasks
As part of this work, I'd like to investigate:
|
16 tasks
ajcvickers
added
punted-for-7.0
Originally planned for the EF Core 7.0 (EF7) release, but moved out due to resource constraints.
and removed
propose-punt
labels
Apr 23, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-migrations
breaking-change
consider-for-next-release
punted-for-6.0
punted-for-7.0
Originally planned for the EF Core 7.0 (EF7) release, but moved out due to resource constraints.
type-enhancement
Current situation
Scaffolded migrations target a specific database provider. This means that it is not in general possible to scaffold a migration against one provider and then use it with another provider.
However, we try to keep the migration "relatively agnostic to the provider" so that there should be only small differences between the migrations for different providers. The most obvious case of this (and perhaps the only one) is that we don't put store types obtained from a type mapping in the migration, because they are very provider-specific. But this has been a source of bugs such as #12212.
So if we drop the "relatively agnostic" part, then we can make provider-specific migrations more robust by removing a source of complexity and bugs.
What changed?
So why did we not take this path already? Well I, for one, believed that it was relatively easy to take two migrations and edit them together into a single migration with some conditional code. Indeed, we even documented this. But it turns out that this isn't easy, because if you want to maintain a full set of migrations that can go up/down for multiple providers, then you also need to merge the model snapshot and the code-behind, both of which are also provider specific. It's hard to believe that many people are doing this, let alone doing it right.
How to we make the experience good
The other way to handle migrations for multiple providers is to have multiple parallel sets of migrations, one for each provider. This is also documented.
However, I think we could make this easier (post-3.0) by annotating the migration with the provider it targets and then adding some support in tooling. For example, #15174 is about throwing if the migration was created for a different provider. But we could extend this to find the right migration from multiple annotated with different provider names.
What should we do now?
Proposal:
The text was updated successfully, but these errors were encountered: