Hi,
I have the following situation:
Base project which has a BaseDbContext containing all my default entities and I load plugins who bring their own DBContext like PluginDbContext. I use EF 6 migrations for both of them which normaly works great, except when I share an entity between two contexts. Like I have an UserProfile entity which is used also by my PluginDbContext.
Now when I create migrations for PluginDbContext it also adds the code for creating/updating the UserProfile entity, but that is already done by the migration from BaseDbContext.
At the moment I solve this problem by simply removing all code from the PluginDbContext migration, which will create "empty migrations" some times.
Now I thought of extending the migrations logic by adding an attribute like "MigratesIn(typeof(DbContext))" (should also be able to take a FQN, so it also is usable if the DbContext is defined in another assembly like it would actually be in my case), because then you could do something like add [MigratesIn(typeof(BaseDbContext))] or [MigratesIn("BaseDbContext, Project.Common")] to the declaration of UserProfile and migratiosn would know, that it should only create migration logic in BaseDbContext migrations, but not in PluginDbContext migrations.
Does this make sense and possible to implement? Or is there already something in EF to do something liek that?
I did not look into the migratiosn code yet, because I wanted to get your opinion on this first, but I am thinking of implementing it if you agree with me it would make sense...
I have the following situation:
Base project which has a BaseDbContext containing all my default entities and I load plugins who bring their own DBContext like PluginDbContext. I use EF 6 migrations for both of them which normaly works great, except when I share an entity between two contexts. Like I have an UserProfile entity which is used also by my PluginDbContext.
Now when I create migrations for PluginDbContext it also adds the code for creating/updating the UserProfile entity, but that is already done by the migration from BaseDbContext.
At the moment I solve this problem by simply removing all code from the PluginDbContext migration, which will create "empty migrations" some times.
Now I thought of extending the migrations logic by adding an attribute like "MigratesIn(typeof(DbContext))" (should also be able to take a FQN, so it also is usable if the DbContext is defined in another assembly like it would actually be in my case), because then you could do something like add [MigratesIn(typeof(BaseDbContext))] or [MigratesIn("BaseDbContext, Project.Common")] to the declaration of UserProfile and migratiosn would know, that it should only create migration logic in BaseDbContext migrations, but not in PluginDbContext migrations.
Does this make sense and possible to implement? Or is there already something in EF to do something liek that?
I did not look into the migratiosn code yet, because I wanted to get your opinion on this first, but I am thinking of implementing it if you agree with me it would make sense...