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