Reputation: 51
I am trying to attach a new entity to the change tracker before SaveChanges is called in EF Core. I currently modify some properties in my own OnBeforeSaving()
method in the DbContext:
private void OnBeforeSaving()
{
var entries = ChangeTracker.Entries();
var utcNow = DateTime.UtcNow;
foreach (var entry in entries)
{
if (entry.Entity is MyObject trackable)
{
switch (entry.State)
{
case EntityState.Modified:
trackable.UpdatedOn = utcNow;
break;
case EntityState.Added:
trackable.CreatedOn = utcNow;
break;
}
AddNewObject();
}
}
}
I have an object that I need to populate when Adding/Updating that would
In the AddNewObject()
method I have tried adding the object to the change tracker but throws an exception InvalidOperationException: Collection was modified; enumeration operation may not execute.
since I am iterating through the change tracker.
private void AddNewObject(MyObject myObject)
{
var newObject = NewObject()
{
propOne = myObject.CreatedOn,
propTwo = myObject.OtherProp
}
ChangeTracker.Context.Attach(newObject).State = EntityState.Added;
}
Is there a way I can attach a new entity from the DbContext before saving?
Upvotes: 1
Views: 582
Reputation: 35083
When it comes to implementing something like an auditing feature for reporting on changes, it can help to isolate the auditing functionality into a separate bounded DbContext that only deals with the audit entity/w relative fields and FKs (if applicable) The audit code would use this completely separate DbContext instance that only cares about the audit row entity with it's populated fields, thus not impacting the change tracker on the main application DbContext.
When it comes to the audit change implementation, this can be done a number of ways. To avoid writing entity-specific implementations or casting to access properties you can opt for using the ChangeTracker
representation of the entity rather than the entity itself to build your audit record. (Getting property names, old and new values) Another alternative is to serialize the entity as JSON or XML to serve as a point in time snapshot, along side the applicable PK/Type info stored in the record. This might involve a little more processing on inspection when reviewing the changes, but that can generally be afforded as the application would be querying this info to display a handful of records at any given time. (I.e. history of changes for a given record)
Upvotes: 1