[
https://issues.apache.org/jira/browse/OPENJPA-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703678#action_12703678
]
Michael Dick commented on OPENJPA-1018:
---------------------------------------
The testcases in question mutate a new entity before committing the
transaction. This is allowed behavior per section 3.5.2 of the JPA
specification :
"The PreUpdate and PostUpdate callbacks occur before and after the database
update operations to
entity data respectively. These database operations may occur at the time the
entity state is updated or
they may occur at the time state is flushed to the database (which may be at
the end of the transaction).
Note that it is implementation-dependent as to whether PreUpdate and PostUpdate
callbacks
occur when an entity is persisted and subsequently modified in a single
transaction or
when an entity is modified and subsequently removed within a single
transaction. Portable
applications should not rely on such behavior."
Julien, in the original scenario does the application make any changes to the
entity after calling persist? If so then the Pre/PostUpdate callback methods
may be invoked. If not then we need to modify TestExceptionsFromCallbacks to
cover this scenario.
> @PreUpdate raised for new entities annotated with @EntityListeners
> ------------------------------------------------------------------
>
> Key: OPENJPA-1018
> URL: https://issues.apache.org/jira/browse/OPENJPA-1018
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.2.0, 1.2.1, 1.3.0, 2.0.0
> Environment:
> http://fisheye6.atlassian.com/browse/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java?r=761031
> Reporter: Julien Kronegg
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Given the following entity:
> @Entity
> @EntityListeners({Auditing.class})
> @Table(...)
> public class A {
> ...
> }
> and the following Auditing class:
> public class Auditing {
> @PreUpdate
> public void preUpdate(Object entity) { // the provided object is
> supposed to be a PersistenceCapable
> ...
> }
> }
> When using runtime enhancement, the PreUpdate event is raised and
> preUpdate(Object) is called when persisting a new entity: the call is not
> expected as the entity is not yet persisted (moreover, the entity passed in
> parameter is not an instance of PersistenceCapable).
> This is due to StateManagerImpl.preFlush() lifecycle event firing conditions:
> // BEFORE_PERSIST is handled during Broker.persist and
> Broker.attach
> if (isDeleted())
> fireLifecycleEvent(LifecycleEvent.BEFORE_DELETE);
> else if (!(isNew() && !isFlushed())
> && (ImplHelper.getUpdateFields(this) !=
> null))
> fireLifecycleEvent(LifecycleEvent.BEFORE_UPDATE);
> When processing a PNewState, the condition for BEFORE_UPDATE event becomes
> simply: isFlushed(), i.e. the BEFORE_UPDATE event is raised for a new Entity!
> (stuff below is supposed to be a boolean table, sorry for the loosy
> presentation):
> isNew
> true.....false
> isFlushed.......true......fire.......fire
> false......X.........fire
> where X means "do nothing" and fire means "fire the BEFORE_UPDATE event".
> The correct full condition would include a condition to prevent raising
> BEFORE_UPDATE for new entities:
> isNew
> true.....false
> isFlushed.......true........X.........fire
> false......X.........fire
> where X means "do nothing" and fire means "fire the BEFORE_UPDATE event",
> which finally gives:
> else if (!isNew() && (ImplHelper.getUpdateFields(this) != null))
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
