openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1018) @PreUpdate raised for new entities annotated with @EntityListeners
Date Tue, 28 Apr 2009 15:35:31 GMT


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
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

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:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.2.0, 1.2.1, 1.3.0, 2.0.0
>         Environment:
>            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
> 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
> where X means "do nothing" and fire means "fire the BEFORE_UPDATE event", which finally
>       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.

View raw message