[
https://issues.apache.org/jira/browse/OPENJPA-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931452#action_12931452
]
Rick Curtis commented on OPENJPA-1873:
--------------------------------------
> I'm very interested why OpenJPA currently loads the dirty fields from the
> database (in a manner which in the logs looks like it's doing multiple
> database interactions!) instead only _loading_ the version (if present).
It sounds like a bug.
> a @PostLoad must get called after loading from the database.
The spec says that @PostLoad must get called after data gets loaded from the
database INTO the persistence context. If the provider is loading from the DB,
but it isn't going into the context, I don't think we need to do the callback.
Also, since OpenJPA has this smart DetachedStateManager, we shouldn't need to
load anything from the database on merge. We currently do (as noted above) but
I think we have a bug.
> 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.