You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Rick Curtis (JIRA)" <ji...@apache.org> on 2010/11/09 00:30:07 UTC

[jira] Commented: (OPENJPA-1873) EntityManager#merge sometimes passes wrong entity values to @PostLoad EntityListeners

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

Rick Curtis commented on OPENJPA-1873:
--------------------------------------

My first thoughts on this are that the merge operation shouldn't result in a postLoad() callback... Nothing from the DB is actually being placed in the persistence context.

The only reason OpenJPA is hitting the DB is to see if the merged Entity is dirty. In the case where there is no version, we need to hit the DB to compare the dirty fields to those in the DB. In the case where there is a version field, we will only load that field... not the entire Entity. 

> 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.