[
https://issues.apache.org/jira/browse/CAY-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2968:
---------------------------------
Fix Version/s: 5.0-M3
> 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
> Fix For: 5.0-M3
>
> Time Spent: 0.5h
> 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)
