[
https://issues.apache.org/jira/browse/CAY-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jadon Hansell updated CAY-2968:
-------------------------------
Description:
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.
was:
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.
> 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)
