[
https://issues.apache.org/jira/browse/OPENJPA-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125297#comment-18125297
]
ASF subversion and git services commented on OPENJPA-2952:
----------------------------------------------------------
Commit 67c6a78ebe8abb7a25715f00597d6b05d2d6c4ee in openjpa's branch
refs/heads/master from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=67c6a78eb ]
[OPENJPA-2952] Require evidence of persistence before assuming detached
The pre-flush check for a relation without cascade treated every
unmanageable instance of a known entity type as detached, without any
evidence that the instance had ever been persisted. The case it was
written for does not need it: an instance of a runtime enhanced
(subclassed) entity type is manageable, so it goes through the state
manager branch below, which confirms the detached state. Drop the block
so that a truly transient instance is reported again.
The datastore probe in that branch ran for every manageable instance
without a state manager, even when the identity of the instance alone
settles the question. Read the primary key values off the instance and
skip the lookup if they show that no identity was ever assigned. The
values cannot be taken from the application identity object, because
that object represents an unset wrapper or primitive primary key as a
zero and so cannot be told apart from an identity of zero, which is how
a flush could probe for and accept a record that has nothing to do with
the instance at hand. A primary key field with a value strategy still
holding the default value of its type counts as unset as well, which is
how OpenJPA reads it when it decides to generate a value; a non-default
version field is evidence of a store record and keeps the lookup.
The probe runs irrespective of the Compatibility property
CheckDatabaseForCascadePersistToDetachedEntity, because for an instance
without persistence state in the current context it is the only
available evidence. Say so in the migration considerations, where that
property is described.
> Transient object wrongly assumed detached in flush check
> --------------------------------------------------------
>
> Key: OPENJPA-2952
> URL: https://issues.apache.org/jira/browse/OPENJPA-2952
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
> Affects Versions: 4.2.0
> Reporter: Maxim Solodovnik
> Priority: Major
> Fix For: 4.2.0
>
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3682999635
> **(medium)** This early-return treats any unmanageable instance of a known
> entity type as detached without verifying it was ever persisted, so a truly
> transient unenhanced object referenced without cascade now passes the check
> and fails later (or silently persists a broken FK). Line 824 also adds
> `_broker.isDetached(obj, true)`, a DB round-trip inside the flush path for
> every manageable object without a state manager. Can both paths at least
> verify a non-null/assigned identity before assuming detached?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
