openjpa-dev mailing list archives

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

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

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

Hi Pinaki!

The test contains a test entity PostLoadListenerEntity.
This  entity contains a field 'value' which I use in the test.
If you add ONE single other value to the entity, the Object in the @PostLoad listener has
a different value.

Please comment out value2 to value12 in this entity (only id and value enabled) and rerun
the test - it will pass now.
Then comment value2 or any other additional field back in -> the test will fail.
This is really inconsistent and should get fixed

Btw I do not agree with you on the value of the @PostLoad data.
The spec says: 
3.5.2
"The PostLoad method for an entity is invoked after the entity has been loaded into the current
persis-
tence context from the database or after the refresh operation has been applied to it."

and for the merge:
3.1.1 "Merge the state of the given entity into the current persistence context." 
3.2.7.1 "The merge operation allows for the propagation of state from detached entities onto
persistent entities managed by the entity manager." + "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."

I interpret this that  the value we need to hand to the @PostLoad method ist per spec the
state of the entity _before_ the merge.
The only thing we imo can take into question is if the @PostLoad needs to get called at all.
Section 3.2.7 at least gives a few answers where we for sure do not need to load it - but
3.2.7.1 imo says that we should for merging detached entities:

3.2 "A managed entity instance is an instance with a persistent identity that is currently
associated with a persistence context."

Of course you can say we don't need to go to the database to ensure the 'managed entity' has
a 'persistent identity' but then you will fail if the database has been changed outside your
application. Thus a load from the database is really required. 

I know that we only need to do what the spec says and not what any other JPA implementation
does. But if 3 other major JPA impls act this way, than it might be a strong indicator at
least ;)

txs and LieGrue,
strub

> 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, postloadtest.zip
>
>
> 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