You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Albert Lee (JIRA)" <ji...@apache.org> on 2008/10/28 22:08:44 UTC
[jira] Commented: (OPENJPA-754) Un-scheduled pre/postUpdate
callbacks from persist.
[ https://issues.apache.org/jira/browse/OPENJPA-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643338#action_12643338 ]
Albert Lee commented on OPENJPA-754:
------------------------------------
The problem is in the condition when the pre/postUpdate events are fired. Specifically in
StateManagerImpl
void preFlush(boolean logical, OpCallbacks call) {
......
else if (!(isNew() && !isFlushed()))
fireLifecycleEvent(LifecycleEvent.BEFORE_UPDATE);
}
The condition reflects the condition when an Insert is NOT performed as determined in
AbstractUpdateManager
protected Collection populateRowManager(.....) {
.......
if (sm.getPCState() == PCState.PNEW && !sm.isFlushed()) {
insert(sm, (ClassMapping) sm.getMetaData(), rowMgr, store,
customs);
} else if (sm.getPCState() == PCState.PNEWFLUSHEDDELETED
|| sm.getPCState() == PCState.PDELETED) {
delete(sm, (ClassMapping) sm.getMetaData(), rowMgr, store,
customs);
} else if ((dirty = ImplHelper.getUpdateFields(sm)) != null) {
update(sm, dirty, (ClassMapping) sm.getMetaData(), rowMgr,
store, customs);
} else if (sm.isVersionUpdateRequired()) {
Therefore the pre/postUpdate should be fired only if an additionally condition if the update is performed. i.e. ImplHelper.getUpdateFields(sm) != null.
Albert Lee.
> Un-scheduled pre/postUpdate callbacks from persist.
> ---------------------------------------------------
>
> Key: OPENJPA-754
> URL: https://issues.apache.org/jira/browse/OPENJPA-754
> Project: OpenJPA
> Issue Type: Sub-task
> Components: kernel
> Affects Versions: 1.0.3, 1.0.4, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.3.0, 2.0.0
> Reporter: Albert Lee
> Assignee: Albert Lee
> Fix For: 1.3.0, 2.0.0
>
>
> In some use case, an unexpected pre/postUpdate callback event will be fired.
> The following operations demonstrate the scenario:
> em.getTransaction().begin();
> // Create and persist a new Message entity
> Message message = new Message("Hello Persistence!");
> message.setId(1);
> em.persist(message);
> em.flush();
> // Create and persist another new Message entity
> message = new Message("Hello Persistence 2!");
> message.setId(2);
> em.persist(message);
> em.getTransaction().commit();
> em.getTransaction().begin();
> message.setMessage("Mutated 2!!");
> em.getTransaction().commit();
> ** PrePersist - Message: id=1, m=Hello Persistence!, create=null, updated=null, v=null
> ** PostPersist - Message: id=1, m=Hello Persistence!, create=null, updated=null, v=1
> ** PrePersist - Message: id=2, m=Hello Persistence 2!, create=null, updated=null, v=null
> ** PreUpdate - Message: id=1, m=Hello Persistence!, create=null, updated=null, v=1
> ** PostPersist - Message: id=2, m=Hello Persistence 2!, create=null, updated=null, v=1
> ** PostUpdate - Message: id=1, m=Hello Persistence!, create=null, updated=null, v=1
> ** PreUpdate - Message: id=2, m=Mutated 2!!, create=null, updated=null, v=1
> ** PostUpdate - Message: id=2, m=Mutated 2!!, create=null, updated=null, v=2
> Albert Lee.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.