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