I implemented similar solution on how we can modify created and updated date upon saving data through EF Core as what is suggested here Populate Created and LastModified automagically in EF Core.
void OnEntityStateChanged(object sender, EntityStateChangedEventArgs e)
{
if (e.NewState == EntityState.Modified && e.Entry.Entity is IHasCreationLastModified entity)
entity.LastModified = DateTime.Now;
}
At first I thought this will be triggered only when SaveChanges() is called. But apparently it is also called on Entry()
// Get entity
var student = _dbContext.Students.Find(studentId);
// Modify student object
student.Name = "New student name";
// Called Entry(), trigger ChangeTracker.StateChanged
var entry = _dbContext.Entry(student);
// Doesn't trigger ChangeTracker.StateChanged
_dbContext.SaveChanges();
I found that ChangeTracker.StateChanged is triggered when _dbContext.Entry(student) is called. Then it doesn't get triggered again when _dbContext.SaveChanges() is called. And it also passes the condition above if (e.NewState == EntityState.Modified && e.Entry.Entity is IHasCreationLastModified entity).
My assumption why it is not triggered again when SaveChanges() is called, because there is no new update to the entity after Entity() is called.
This results in the LastModified property being assigned when .Entry(student) is called, instead of when .SaveChanges() is called.
Is there a way to only update LastModified property once when SaveChanges is called on the scenario above?
I suggest that you could override you SaveChanges method in your dbContext. You could refer to below code that I usually use.
public class ForumContext : DbContext
{
public ForumContext(DbContextOptions<ForumContext> options) : base(options)
{
}
//other settings
public override int SaveChanges(bool acceptAllChangesOnSuccess)
{
foreach (var entry in ChangeTracker.Entries())
{
switch (entry.State)
{
case EntityState.Added:
((BaseEntity)entry.Entity).AddedDate = DateTime.Now;
((BaseEntity)entry.Entity).LastModified = DateTime.Now;
break;
case EntityState.Modified:
((BaseEntity)entry.Entity).LastModified = DateTime.Now;
break;
case EntityState.Deleted:
entry.State = EntityState.Modified;
entry.CurrentValues["IsDeleted"] = true;
break;
}
}
return base.SaveChanges(acceptAllChangesOnSuccess);
}
I thought you might like to know why you were getting the the events you saw in your question.
When you execute the line student.Name = "New student name";, then, by default, nothing happens because EF Core hasn't called the ChangeTracker.DetectChanges method yet so it doesn't know anything has changed.
But the call to var entry = _dbContext.Entry(student); then runs a version of the ChangeTracker.DetectChanges - see the code below taken from the EF Core code.
public virtual EntityEntry<TEntity> Entry<TEntity>([NotNull] TEntity entity) where TEntity : class
{
Check.NotNull<TEntity>(entity, nameof (entity));
this.CheckDisposed();
EntityEntry<TEntity> entityEntry = this.EntryWithoutDetectChanges<TEntity>(entity);
//My comment - this runs a version of the DetectChanges method.
this.TryDetectChanges((EntityEntry) entityEntry);
return entityEntry;
}
EF Core's Entry method does this because you might ask for the State of the entity and therefore it has to call DetectChanges to make sure its up to date.
Now, it turns out that if you do the following
student.Name = "New student name";
_dbContext.SaveChanges();
Then (in EF Core 5 preview, but I think it is the same in EF Core 3.1) you get two events.
OldState.EntityState == Unchanged, newState.EntityState == Modified - that is triggered by the call to DetectChanges.
OldState.EntityState == Modified, newState.EntityState == Unchanged - that is triggered by SaveChanges when it set the state to say the database matches the entity class.
If you do the following
student.Name = "New student name";
var entry = _dbContext.Entry(student);
_dbContext.SaveChanges();
Then you would get the same events. The DetectChanges would be called twice (once by Entry and once by SaveChanges), but there is no change in the State on the second call the DetectChanges
You can see this in my unit tests in the repo I am writing to support my book Entity Framework Core in Action. I'm writing the section on these events and found your question and though I would answer it.
I hope it helps you understand what is going on, but I should say that the other answers suggesting overriding SaveChanges is a better solution than using these events.
Related
I have an WPF project, MVVM with an EF6 dataset and I'm looking to implement a way to rollback all changes.
The following code shows how ViewModel loads the data:
protected async override void GetData()
{
ThrobberVisible = Visibility.Visible;
ObservableCollection<MobileDeviceRequestVM> _requests = new ObservableCollection<MobileDeviceRequestVM>();
var requests = await (from c in dbContext.MobileDeviceRequests
orderby c.RequestDate
select c)
.ToListAsync();
foreach (MobileDeviceRequest req in requests)
{
_requests.Add(new MobileDeviceRequestVM { IsNew = false, TheEntity = req });
}
MobileDeviceRequests = _requests;
RaisePropertyChanged("MobileDeviceRequests");
ThrobberVisible = Visibility.Collapsed;
}
The following code shows how the ViewModel rolls back any changes:
protected override void RollbackData()
{
var changedEntries = dbContext.ChangeTracker.Entries()
.Where(x => x.State != EntityState.Unchanged).ToList();
foreach (var entry in changedEntries)
{
switch (entry.State)
{
case EntityState.Modified:
entry.CurrentValues.SetValues(entry.OriginalValues);
entry.State = EntityState.Unchanged;
break;
case EntityState.Added:
entry.State = EntityState.Detached;
break;
case EntityState.Deleted:
entry.State = EntityState.Unchanged;
break;
}
}
//Somewhere in here the OC: MobileDeviceRequests needs to get refreshed
//with the context as items may have been added and/or deleted
RaisePropertyChanged("MobileDeviceRequests");
}
The following code shows how the ViewModel refreshes the data, which may or may not rollback data depending on if something has changed:
protected virtual void RefreshData()
{
GetData();
}
The following creates a new context
protected virtual void ReloadData()
{
dbContext= new BAContext();
GetData();
}
What I'm wondering about is:
Rolling Back
vs
Refreshing
vs
Reloading
They all seem to do virtually the same thing, the ReloadData() being the more expensive.
I guess what I'm asking is, if refresh does the requery and populates the OC, is there any point in having a rollback. If there is, then how would you repopulate the OC and would it be any different than the refresh?
The aforementioned methods are not equivalent.
When executing LINQ to Entities tracking query, EF will requery the database, but then will take into account the current change tracker state of the returned entities, and will return the local entity data rather than actual data. The concept is similar to the RefreshMode.ClientWins options of the older ObjectContext.Refresh method.
The net effect of your refresh will be that it eventually will bring the new data (added to the database through different context instance or another process/user). But the current modifications will stay in effect.
So IMO you the options are just two - rollback the current or use new context. The way you implemented it, rollback method seems to work, but entity queries still will not apply changes made outside the context instance. But this applies to the tracked entity queries in a long lived context anyway, so probably might not be considered a defect.
Which one of the two you choose depends on your requirements. But the only guaranteed way to start really fresh is to use a new context instance.
For performance reasons I have AutoDetectChangesEnabled = false on the DbContext.
Updating simple properties and reference properties all works fine but I am having trouble with collection properties that are many-to-many and don't have a joining class.
This is abbreviated code trying to add to the collection:
var item = context.Set<Item>().FirstOrDefault();
var category = context.Set<Category>().FirstDefault();
context.Entry(item).Collection(i => i.Categories).CurrentValue.Add(category);
But it does nothing, after SaveChanges the database is same as it was. Is this the correct way to be doing this?
Call:
context.ChangeTracker.DetectChanges();
Or:
context.Entry(item).State = EntityState.Modified;
I always thought that EF executed DetectChanges as part of SaveChanges no matter what. But inspecting the source code reveals that even then DetectChanges isn't executed when AutoDetectChangesEnabled is false.
I think in your case, the best you can do is override SaveChanges so it will always detect changes before saving:
public override int SaveChanges()
{
var detectChanges = this.Configuration.AutoDetectChangesEnabled;
try
{
this.Configuration.AutoDetectChangesEnabled = true;
return base.SaveChanges();
}
finally
{
this.Configuration.AutoDetectChangesEnabled = detectChanges;
}
}
An alternative would be to call ChangeTracker.DetectChanges(); in the override, but by setting AutoDetectChangesEnabled = true, EF itself will choose the moment when to call DetectChanges during SaveChanges, which seems preferable to me.
I'm trying to copy an entity from one DbContext to another.
So I'm loading and detaching the entity before calling the save methods of the other DbContext.
EDIT:
First of all I'm loading the entity with the ID of the UserDT, then I'm detaching it from the old DbContext.
Finally I'l set SET IDENTITY_INSERT tUsers ON, save the entity and then turn SET IDENTITY_INSERT tUsers OFF.
var userEntity = DataContext.GetById<User>(id);
DataContext.EnsureDetached(userEntity);
offlineContext.ToggleIdentityInsert(true, typeof(User));
offlineContext.SetSaved(userEntity);
offlineContext.SaveChanges();
offlineContext.ToggleIdentityInsert(false, typeof(User));
Before DbContext.SaveChanges() I call this method (please note that this method is in a class inheriting from DbContext):
public T SetSaved<T>(T obj) where T : class, IEntity
{
var isNew = base.Set<T>().All(t => t.Id != obj.Id);
T ret = default(T);
var entry = Entry(obj);
if (isNew)
{
entry.State = EntityState.Added;
ret = base.Set<T>().Add(obj);
}
else
{
entry.State = EntityState.Modified;
}
return ret;
}
All entities I've used so far worked with this method.
Our User entity causes a NullReferenceException when calling this method, because the the properties CurrentValues and OriginalValues throw an InvalidOperationException saying that the entity is not attached to the current DbContext.
With this problem I can access the State and then add the obj to the DbContex.
EDIT:
I've forgot to say that the above code works on the second try. In my scenario I'm pressing the login button and the logged in user should be copied (offline DB). The first time I'll get the error, the second time I press the login button everything works fine.
Do you know what I could have forgotten?
I received this exception while debugging in VS 2012
An object with the same key already exists in the ObjectStateManager.
The ObjectStateManager cannot track multiple objects with the same
key.
//_dbSet declaration:
private readonly IDbSet<T> _dbSet;
//Method parameter
public virtual void Update(T entity)
//method fragment
public virtual void Update(T entity)
{
if (Entities == null) return;
var entry = Entities.Entry(entity);
switch (entry.State)
{
case EntityState.Modified:
var currentValues = entry.CurrentValues.Clone();
entry.Reload();
switch (entry.State)
{
case EntityState.Detached:
Entities.Entry(entry).State = EntityState.Modified;
break;
default:
entry.Reload();
entry.CurrentValues.SetValues(currentValues);
break;
}
break;
case EntityState.Detached:
_dbSet.Attach(entity); /*Here is the thing*/
entry.CurrentValues.SetValues(entity);
break;
}
Entities.Commit();
}
I have spent almost a week trying to solve optimistic concurrency with these patterns:
DbFactory, Unit of Work, DI, Generic Repository, without getting results.
I believe the exception message is clear enough:
An entity with the same key (that is, an entity that maps to the same database record) has already been loaded and attached in the target DbSet.
What you decide to do in that case is entirely up to you:
You can get the already loaded equivalent entry and modify the values of the attached equivalent to match the entity instance (or anything more complicated);
You can detach the equivalent loaded entry and attach your parameter entity instead;
You can just skip over it;
The code smells bad;
The first switch statement uses the entry.State and checking whether the entity is in modified state or in detached state; then in the modified case , a new switch statement is created to check whether the entity is detached or in other state.
The exception states nothing about the optimistic concurrency; instead it states that you are trying to attach an entity to the object context and an entity with the same key already exists in the context.
I would like to thank all of whom dedicated a bit of their precious time to my headake.
Here is a new post clearifying my final solution for concurrent Update method in Generic Repository pattern. Nothing was lost thanks to this article:
Seeking Entity's Key by Attribute Along
That was very useful: RoccoC5
private object GetKeyValue(T entity)
{
var key =
typeof(T).GetProperties().FirstOrDefault(
p => p.GetCustomAttributes(typeof(KeyAttribute), true).Length != 0);
return (key != null) ? key.GetValue(entity, null) : null;
}
public virtual void Update(T entity)
{
if (Entities == null) return;
var key = GetKeyValue(entity);
var originalEntity = _dbSet.Find(key);
Entities.Entry(originalEntity).CurrentValues.SetValues(entity);
Entities.Commit();
}
What is the proper and fast way to save combined new and modified detached POCO entities?
I was thinking about these methods:
private void Method_2(IList<Entity> entities) //detached entities
{
//This method is using SELECT to check if entity exist
using (var context = new ModelContainer())
{
foreach (Entity entity in entities)
{
var foundEntity = context.CreateObjectSet<Entity>().SingleOrDefault(t => t.Id == entity.Id);
context.Detach(foundEntity); //Remove it from ObjectStateManager
if (foundEntity != null)//It is modified entity
{
context.AttachTo("EntitySet", entity); //Attach our entity
context.ObjectStateManager.ChangeObjectState(entity, EntityState.Modified); //We know it exists
}
else//It is new entity
{
context.CreateObjectSet<Entity>().AddObject(entity);
}
}
context.SaveChanges();
}
}
private void Method_1(IList<Entity> entities) //detached entities
{
//This method doesn't select anything from DB, but i have ta call Savechanges after each object
using (var context = new ModelContainer())
{
foreach (Entity entity in entities)
{
try
{
context.AttachTo("EntitySet", entity);
context.ObjectStateManager.ChangeObjectState(entity, EntityState.Modified);
context.SaveChanges();
}
catch (OptimisticConcurrencyException)
{
context.ObjectStateManager.ChangeObjectState(entity, EntityState.Added);
context.SaveChanges();
}
}
}
}
When you are working in detached environment you have to know which entity was added and which is modified - it is your responsibility to keep this information and provide it to ObjectContext.
Well i agree with this statement if you found yourself in situation when you need to use EF code like this in EF definitely something is wrong with you decision. I have chosen wrong tool for this job.
When you are working in detached environment you have to know which entity was added and which is modified - it is your responsibility to keep this information and provide it to ObjectContext.
The very easy way is:
foreach (var entity in entities)
{
if (entity.Id == 0) // 0 = default value: means new entity
{
// Add object
}
else
{
// Attach object and set state to modified
}
}
The example requires that you have some db auto-generated primary key (Id).
Your Method 2 is possible with some modifications. It is not needed to detach entity when you load it. Instead use ApplyCurrentValues. The approach with loading entity first is very usefull when you decide to work with object graphs instead of single entity. But in the case of object graph you have to do synchronization manually. ApplyCurrentValues works only for scalar (non navigation) properties. You can try to futher optimize your method to load needed enitites in single roundtrip to database instead of loading entities one by one.
Your Method 1 is terrible solution. Using exceptions raised on database server to control program flow is bad approach.
I agree with #Ladislav - Method_1 is a bad approach. Let the database raise exceptions which are caught by EF - don't try and swallow these exceptions yourself.
Your on the right track with Method 1.
Here is how i do it - as i also have a detached context (POCO's, no change tracking, ASP.NET MVC).
BLL Interface: (note i have TPT in my model, hence generics. "Post" is abstract)
void Add(Post post);
void Update<TPost>(TPost post) where TPost : Post, new();
The new() constraint is crucial - you'll see why shortly.
I won't show how i do "Add", because it's simple as you think - AddObject(entity);
The "Update" is the tricky part:
public class GenericRepository<T> : IRepository<T> where T : class
{
public void Update<T2>(T2 entity) where T2: class, new()
{
var stub = new T2(); // create stub, now you see why we need new() constraint
object entityKey = null;
// ..snip code to get entity key via attribute on all domain entities
// once we have key, set on stub.
// check if entity is already attached..
ObjectStateEntry entry;
bool attach;
if (CurrentContext.ObjectStateManager.TryGetObjectStateEntry(CurrentContext.CreateEntityKey(CurrentContext.GetEntityName<T>(), stub), out entry))
{
// Re-attach if necessary.
attach = entry.State == EntityState.Detached;
}
else
{
// Attach for first time.
attach = true;
}
if (attach)
CurrentEntitySet.Attach(stub as T);
// Update Model. (override stub values attached to graph)
CurrentContext.ApplyCurrentValues(CurrentContext.GetEntityName<T>(), entity);
}
}
And that works for me.
As for the entity key, i have used attributes on my domain classes. An alternative (which i'm about to move to), is have all my domain entities implement an interface, which specifies that all domain entities must have a property called "EntityKey". Then i'll use that interface on my constraints. Basically, i needed a dynamic way to create stub entities in a generic repository.
I don't personally like the idea of "checking the ID, if its > 0 then it's an update". Because i'm working with ASP.NET MVC, if i (or another developer) forgets to bind the ID to the View, it won't be passed through, so even though it may be an update, because the ID == 0 it will be added.
I like to be explicit about the operations. This way, i can perform Add/Update seperate validation logic.
Perhaps take a look at Self Tracking POCO entities. IMHO they are perfect for any scenario that requires the entity to be separated from the context. It takes care of all the plumbing code for you.