I'm developing a plugin application with EF6, code first.
I have one main context with an entity called User
:
public class MainDataContext : DbContext
{
public MainDataContext(): base("MainDataContextCS") {}
public DbSet<User> Users { get; set; }
}
And then another context for PluginX, on another project which references the base one:
public class PluginDataContext : DbContext
{
public PluginDataContext () : base("MainDataContextCS") {
}
protected override void OnModelCreating(DbModelBuilder modelBuilder) {
modelBuilder.HasDefaultSchema("PluginX");
base.OnModelCreating(modelBuilder);
}
public DbSet<Booking> Bookings { get; set; }
}
And this neatly creates, on the same Database (same connection string), the PluginX.Bookings
Table.
The problem here is that the Booking
entity contains a reference to User
entity:
public class Booking
{
public int Id { get; set;}
public virtual User CreationUser { get; set;}
public BookingStatus Status { get; set; }
}
And when running Add-Migration
for the plugin context EF will try to create another User
entity called PluginX.User
.
How can this be solved? Is there a way to share a common entity, in another DbContext
?
DbContext should not be used as a singleton because it is holding a connection object which cannot be used by multiple threads at the same time.
But if you use other injected services, with "transient" on the DBContext, every service gets his own instance of it. In order to avoid that you should always use "scoped" on the DBContext. Correct. Maybe there are cases in which you need a transient EF-Context - but usually you should stick to scoped.
This is usually caused by different threads using the same instance of DbContext, however instance members are not guaranteed to be thread safe. When concurrent access goes undetected, it can result in undefined behavior, application crashes and data corruption.
Don't dispose DbContext objects. Although the DbContext implements IDisposable , you shouldn't manually dispose it, nor should you wrap it in a using statement. DbContext manages its own lifetime; when your data access request is completed, DbContext will automatically close the database connection for you.
When you work with multiple contexts you have two options:
When you add the Booking entity, don't use the DbSet.Add()
method. Instead use the DbSet.Attach()
method and set the DbContext.Entry(Entity).State
property for the Booking to EntityState.Added
and make sure the DbContext.Entry(Entity).State
for User stays EntityState.Unchanged
.
So for example instead of doing this:
pluginDataContext.dbBooking.Add(myNewBooking);
Do this:
pluginDataContext.dbBooking.Attach(myNewBooking);
pluginDataContext.Entry(myNewBooking).State = EntityState.Added;
This is because the Add()
method marks all entities in the object graph as EntityState.Added
which will cause inserts without checking if the entity already exists in the database. The Attach()
method simply makes the context begin tracking the entity.
This is why I almost never use DbSet.Add()
.
You can try using views, declare the user as a view in PluginDataContext and when you perform the migration, type the method "create User view as ...", this allows you to relate the book to the user.
This solution could help you:Entity Framework 6 Code First Migrations with Multiple Data Contexts. However, in this case, both context are in the same project. I don't know if works with contexts that are in two different projects (I think it should if you are using the same class to map User). As the blog said, you need to comment the generated code related to the Users table when you run the Add-Migration
command for the PluginX Context.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With