Redundant Add when using notification entites

[sjb-sjb]

When I set a navigation property in a notification-tracking entity, the referenced (primary) entity is added to the context (resulting State is Added) even if the referenced entity already has a store-assigned primary key.

I understand why the referenced entity needs to be added if the primary key has not been created (e.g. a long with value zero) because EF needs a unique pseudo-key until the first time the entity is stored (e.g. a negative temporary key assigned by EF). However EF still adds the entity even if there is a valid (e.g. positive) store-generated key. This results in an attempt to write the entity again to the database, which cannot be done since the primary key already exists.

EF should not attach the entity to the context in this case.

[sjb-sjb]

I would note that the entity definitely does need to be added to the context in order to create the temporary key value. Even though logically they are separate concepts, if you do not add the entity to the context then the Id values (both in the entity itself and in the dependent entity) will not be reset to the actual store-generated key after the SaveChanges.

[ajcvickers]

The typical scenario for adding a new entity instance to an already-tracked graph is that the new entity instance represents a new entity, not an entity that exists in the database but was not being tracked. Therefore, the behavior, both in classic EF, and in EF Core is to mark the entity as Added. However, I have been thinking about this recently and I just filed #13575 to potentially change this behavior.

[sjb-sjb]

To highlight, the point is that EF is automatically attaching the entity when I don't want it to (don't expect it to & can't prevent it).

Consideration should be given to allowing fine-grained control over when an entity is attached to a context. The distinction made in EF Core between calling Add and setting State=Added is an example of providing control over whether and when EF automatically / implicitly starts tracking an entity. A systematic review should be done to find all other situations in which EF automatically starts tracking an entity (such as the above when a navigation property is set on a change-notifying entity) and make sure that there is a straightforward way for the user to disable the automatic start-tracking.

Question: in the situation described (attached dependent entity's navigation property is set to a point to a principal entity that already has a store-generated key) the principal entity's state becomes Added. Is this due to an implicit Add or due to an implicit State=Added ? The difference being, obviously, whether entities reachable from the principal entity are also Added (implicit Add) or not (implicit State=Added).

An easy fix to these issues might be to check, in Add, whether there is a store-generated key that is already set and if so then either do an Attach instead or do not attach at all; with the choice being configured in the model builder. One might also want an option to keep the current behavior (or to choose between adding the entity via Add or adding it via State=Added).

[ajcvickers]

We discussed this in triage and will either update an existing event or add a new one to allow tracking of an entity to be cancelled.

[sjb-sjb]

A related documentation issue is: what are all of the entity state transitions that can possibly occur and under what circumstances does each occur, and what are the associated states of the primary key (i.e. negative pseudo-key, zero, or positive key) before and after the transition?

[sjb-sjb]

For reference I am quoting part of my Oct 10 comment in #13575:

"I tried to workaround by setting state back to Detached if it I didn't want the Detached --> Added transition. However for some reason EF then re-attached it again, resulting in an infinite cycle Detached --> Added --> Detached --> Added etc. This problem went away when I set the state to Unchanged instead of Detached. I do end up with an Unchanged entity attached to my context that I would rather not have attached, but this is not a big efficiency hit in my situation."

I can imagine this cropping up when you implement the Add-suppressing modification to the event, as suggested above.