[
https://issues.apache.org/jira/browse/CAY-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18092777#comment-18092777
]
Jadon Hansell commented on CAY-2968:
------------------------------------
Submitted a pull request with breaking tests and a fix. Alongside the test for
the joint prefetch, I also included tests for disjoint and disjoint-by-id
prefetches for completeness. Those two are passing on master without the fix.
https://github.com/apache/cayenne/pull/645
> 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
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
