You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To use some ancient EF4 terminology, today's EF Core query behavior uses MergeOptions.AppendOnly. This means that new entities are materialized and attached to the state manager while any entities that already exist in the state manager (as identified by their key) are returned as is. This means that any new property values returned by the query are essentially discarded.
I would like the option of using the PreserveChanges behavior. This would update the original and current values of any existing entities' unchanged properties. This is obviously more computationally expensive, but I suspect it will be offset by the memory allocations saved in comparison to existing new-DbContext/NoTracking/ChangeTracker.Clear workarounds.
The text was updated successfully, but these errors were encountered:
I seem to remember us discussing implementing such "merge" behavior in the past, @AndriySvyryd any idea if we have an issue already tracking this etc.?
Just noting that new-DbContext/NoTracking/ChangeTracker.Clear are about totally overriding the currently tracked entities - regardless of whether they've changed or not (whereas above you're proposing more of a merge, where only unchanged properties get updated with the new values from the database).
To use some ancient EF4 terminology, today's EF Core query behavior uses
MergeOptions.AppendOnly
. This means that new entities are materialized and attached to the state manager while any entities that already exist in the state manager (as identified by their key) are returned as is. This means that any new property values returned by the query are essentially discarded.I would like the option of using the
PreserveChanges
behavior. This would update the original and current values of any existing entities' unchanged properties. This is obviously more computationally expensive, but I suspect it will be offset by the memory allocations saved in comparison to existing new-DbContext/NoTracking/ChangeTracker.Clear workarounds.The text was updated successfully, but these errors were encountered: