[
https://issues.apache.org/jira/browse/OPENJPA-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932653#action_12932653
]
Pinaki Poddar commented on OPENJPA-1873:
----------------------------------------
Mark,
1. is the attached test in PostLoadTest.zip supposed to pass or fail?
you wrote:
> Fact: a @PostLoad must get called after loading from the database. Thus I'd
> say that it needs to get called even if entities only got loaded partly.
I tend of agree. The notion of 'loaded partly' does not exist in the spce --
it is an implementation issue.
However, my view is that the lifecycle callback methods are tied to instance
life cycle state transitions and not directly to operational methods such as
find() or merge(). Of course, an operational method may cause a life cycle
state transition. For example, a PostLoad callback is invoked when an entity
state is loaded from the database. But whether a merge() operation will cause
an entity state be loaded from database or not can vary based on other factors.
Hence a question such as "does merge() must invoke postLoad()?" may not offer a
definite answer. "Vendor X invoked postLoad() on merge()" -- is not convincing
enough for me.
> But the spec also defines that the _entity_ from the db needs to get posted.
Can you please elaborate this point? Are you suggesting that the state of
the argument instance of postLoad() method should represent the database
values? If that is the case, then I do not agree. The postLoad() will see the
state of the instance *after* the provider has loaded the instance in to its
context -- some of the properties can come from the database, some can come
from the user-supplied instance -- but the state as presented to the
postLoad() method argument must be 'consistent' -- meaning it must be the exact
same state that the persistence context holds and will eventually be committed
if nothing changes further.
> Currently we get a mix between old and new values in @PostLoad which (I think
> we agree) is wrong.
Such a mix, if proven, is inconsistent. But I could not see how the test you
have submitted exposes such inconsistent behavior.
> 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.
