-
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
Feature request: Migrations on Inherited DbContexes #5572
Comments
This is already covered by an existing item on our backlog #2725. I've added a note to that issue to specifically consider the inherited context scenario when looking at it. |
Thank you. I have not seen it. Is there a workaround currently? |
The workaround is to just remove any operations on them that get scaffolded in the migration. |
I'm already doing it, I could not find a better way yet. Thanks. |
Question, how are you handling injection of DbContextOptions ? Or you are not injecting them? |
Hi,
Situation
Assume that we have created a modular application and we have more than one DbContext.
Example: In our core part of the application, we have a CommonDbContext:
And we have several modules (in their own assemblies), like:
In this case, I want to have 3 separated migrations normally:
At this point, as you know, derived DbContext's automatic migration generation code include base DbContext (CommonDbContext) changes. While this can be desired in some situations, as you see it's not good for my application.
Feature Request
Define an attribute (and a method in fluent configuration) to ignore base changes:
Entity Framework migration generator should understand IgnoreBaseDbContextMigrations attribute and should not detect base class changes.
IgnoreBaseDbContextMigrations can be enhanced. For example, we may supply a DbContext class type to indicate which will be ignored, and so on... Also, there can be technical problems on some situations (for example, on entity inheritance) which should be thought carefully.
What do you think for such a feature, or do you know any other approach to implement the same requirement?
The text was updated successfully, but these errors were encountered: