Don't consider a generated value stable just because it was explicitly set

[ajcvickers]

Fixes #32084

[AndriySvyryd]

This is a breaking change for the cases where the PK is not an FK, has a non-stable value generator and is assigned an explicit value

[ajcvickers]

This is a breaking change for the cases where the PK is not an FK, has a non-stable value generator and is assigned an explicit value

Are you sure? We always start with

        var hasStableValues = false;
        var hasNonStableValues = false;

In the new code we see the property has a non-stable generator, so in one case hasNonStableValues becomes true.

We then:

return hasStableValues && !hasNonStableValues;

Which is false in both cases.

Or does there also have to be a stable generator in there for the break you are thinking of?

[AndriySvyryd]

Or does there also have to be a stable generator in there for the break you are thinking of?

Sorry, it just needs to be one stable generator, like the one we use in Cosmos.

[ajcvickers]

Or does there also have to be a stable generator in there for the break you are thinking of?

Sorry, it just needs to be one stable generator, like the one we use in Cosmos.

So you mean PK: yes; FK: no; Explicit value: no; stable generator: yes?

[ajcvickers]

@AndriySvyryd Wrote taste cases that execute this path. The behavior has changed when detecting changes and a new entity is found that has an explicitly set stable value for its PK. We previous detected this as Modified, as we would if the value was non-stable and explicitly set, but the presence of a stable value does not indicate that the entity must already exist, so the correct thing to do is fall back to Added.