openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-1873) EntityManager#merge sometimes passes wrong entity values to @PostLoad EntityListeners
Date Tue, 09 Nov 2010 15:31:09 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12930166#action_12930166
] 

Kevin Sutter commented on OPENJPA-1873:
---------------------------------------

Hi guys,
My two cents worth...  I don't think the spec indicates that the @PostLoad should get fired
on a merge() operation.  I do agree that if the merge() operation requires loading from the
database, then the @PostLoad should get fired.  But, I don't see in the spec where it says
that the merge() operation demands a load from the database (and thus the @PostLoad).

Section 3.2.7.1 states:

"If X is a detached entity, the state of X is copied onto a pre-existing managed entity instance
X'
of the same identity or a new managed copy X' of X is created."

Since OpenJPA utilizes a "detached state manager", that would constitute a pre-existing managed
entity instance and there would be no requirement to go to the database.  If you think about
it, this would be a good thing to avoid extra, unnecessary trips to the database.

Now, if your detached entity does not use a "detached state manger" [1], then we probably
have to go to the database (like the other providers) to load up the current state into a
new managed copy and then merge in the updated values.  From side conversations with Rick,
this processing may not be working quite right, but that's how I am reading the spec and the
scenario described here.

The other interesting piece from 3.2.7.1 is this:

"Any Version columns used by the entity must be checked by the persistence runtime implementation
during the merge operation and/or at flush or commit time. In the absence of Version columns
there is
no additional version checking done by the persistence provider runtime during the merge operation."

Earlier comments by Rick seemed to indicate that the absence of an @Version field would be
a reason to access the database during merge().  This paragraph seems to indicate that this
version checking should not be done during merge()...

This looks to be a good problem.  I think we have an issue or two to resolve here.  We just
need to come to a consensus.

Thanks,
Kevin

[1]  http://openjpa.apache.org/builds/2.0.1/apache-openjpa-2.0.1/docs/manual/manual.html#ref_guide_detach_state


> EntityManager#merge sometimes passes wrong entity values to @PostLoad EntityListeners

> --------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1873
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1873
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 2.0.0, 2.0.1, 2.0.2
>            Reporter: Mark Struberg
>         Attachments: OPENJPA-1873-unittest.patch
>
>
> I've tested this with the latest from branches/2.0.x.
> My entity has an @EntityListeners which observes the @PostLoad lifecycle event. This
listener stores the 'old' values from the database for later use (see http://struberg.wordpress.com/2010/07/31/howto-changelog-with-jpa/
for the intention behind). All works well if the table has only a few rows. But if you add
more rows, OpenJPA tries to optimize the access and only loads the @Version field + the dirty
fields. In this case the merging seems to be wrong, because I get the NEW values from the
dirty fields instead of the original values from the database passed to my @PostLoad method.
> Did cost me a few grey hairs to track down the differences between the working and the
broken scenarios here ;) But finally I was able to creat a unit test showing the problem

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message