[
https://issues.apache.org/jira/browse/OPENJPA-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12930171#action_12930171
]
Rick Curtis commented on OPENJPA-1873:
--------------------------------------
> but it seems that EclipseLink and Hibernate both fire the @PostLoad event for
> a merge.
Point noted.
3.5.2 -- "The PostLoad method for an entity is invoked after the entity has
been loaded into the current persistence
context from the database or after the refresh operation has been applied to
it."
Most of my argument is based off the part which says "from the database". In
the case of this merge, OpenJPA has a DetachedStateManager so we *shouldn't*
need to hit to DB to see which fields are dirty. I think we have a bug here
where we hit the DB even though we don't need to.
I believe that the other providers aren't working per the spec. Upon merge
being called, they may need to hit the DB to compare merged fields with those
in the DB to see which are dirty/clean... but that data isn't actually loaded
into the persistence context. They are loading data for the sake of version
checking, not for loading in the context.
I'll note that Pinaki wrote a blog post[1] quite some time back doing something
very similar. It might be worth a read. It looks like the formatting is messed
up so let me know if you want the full text.
Quite the hair splitting for this early in the morning :)
[1] http://webspherepersistence.blogspot.com/2009/01/auditing-with-openjpa.html
> 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.
