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

Mark Struberg commented on OPENJPA-1873:
----------------------------------------

I did further debugging.

In the DetachedStateManager #165 (right after the dirty check and reload of all 
those fields: Object origVersion = sm.getVersion(); ) the sm (StateManagerImpl) 
contains the correct entity values from the db in _pc!

of course they get replaced with the values from toAttach before the @PostLoad 
gets fired.

There are 2 options now:

a) dont fire the @PostLoad at all for EM#merge - because the load data in the 
event is definitely wrong currently
b) first merge the non-dirty fields back to the sm._pc before firing the 
@PostLoad event and then do the toAttach merge.

I'd obviously prefer option b ;)

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

Reply via email to