Jadon Hansell created CAY-2968:
----------------------------------
Summary: Vertical Inheritance: INSERT instead of UPDATE after
updating flattened attribute
Key: CAY-2968
URL: https://issues.apache.org/jira/browse/CAY-2968
Project: Cayenne
Issue Type: Bug
Affects Versions: 4.2.2, 5.0-M2
Reporter: Jadon Hansell
Updating a dependent-table attribute on a vertical-inheritance object and
committing triggers an INSERT (with all columns {{null}} except the PK and the
changed column) instead of an UPDATE. This causes a duplicate PK error.
The flush decides insert-vs-update from the flattened {{ObjectId}} recorded via
{{ObjectStore.markFlattenedPath}}; when that id is missing or mis-keyed, the
dependent row looks new. There are three independent defects with this same
symptom, each at a different site:
1. Joint prefetch: {{PrefetchProcessorJointNode}}
A non-phantom joint prefetch of a VI child entity causes this issue. The joint
SQL doesn't select the dependent entities' PK columns, so {{ObjectResolver}}
can't resolve the flattened id from the result row.
2. Shared snapshot cache: {{DataContextSnapshotBuilder}}
An object faulted from a cached {{DataRow}} (e.g. an {{objectForPK}} in
a fresh context served from the snapshot cache rather than a fresh DB read)
triggers this issue. The cached snapshot is built without the dependent
entities' PK values, so there's no flattened id.
3. Three-level inheritance: {{ObjectResolver}}
It looks like this was an existing regression from CAY-2552. As a part of that
ticket, {{DescriptorColumnExtractor.visitAttribute}} migrated flattened data
row keys from using the last segment of the path to using the whole path.
{{ObjectResolver.resolveAdditionalIds}} wasn't updated as a part of that, so it
is still only looking at the last segment of the path. This causes it to read
{{b.ID}} instead of {{a.b.ID}} and trigger this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
