Yes, PreUpdate() is useful for many purposes (Auditing, for example). But a PreUpdate() callback method should be restricted to modify only the basic fields of a given entity. If it is allowed to modify its references to other entities or other second-class objects (e.g. adding removing members of a related collection) then that can be a non-trivial (or even non-tractable) problem to solve during flush/commit cycle due to re-entrancy.
Simone Gianni wrote: > > I'm not a JPA expert, but I do totally agree : at least from a user POV > it's quite natural to use the callback method to update the entity. > Also, the OpenJPA documentation states that it is possible to do so : > > "methods annotated with |PreUpdate| is normally used to set persistent > fields with information cached in non-persistent data." > http://openjpa.apache.org/builds/latest/docs/manual/manual.html#jpa_overview_pc_callbacks > > It explicitly say "set persistent fields", which for a user means > calling entity.setSomething(), and also that it is normal. The only > problem I can foresee is when there are more than one EntityListener, > the first one checking the value of a field, and another one changing > that value at a later time ... but that belongs to the application logic > domain, the only support should be to make sure the user can explicitly > state the order EntityListeners are called to make sure modification > happen before checks if business logic requires that. > > Also in Hibernate "pre-JPA" it was possible to update an entity from a > listener; haven't used Hibernate as a JPA ORM but I think there is no > good reason why they should have changed this. > > Simone > > Michael Dick wrote: >> I think there may be valid use cases where updating *the* entity in a >> PreUpdate callback method is valid. One example might be implementing a >> wiki. >> >> On each update of a page you may want to update the version and update a >> lastUpdatedBy attribute with the userid that made the update. The >> PreUpdate >> callback is a fairly logical place to make such a change. >> >> Absent a compelling reason why an application can't update the entity in >> a >> callback method I'm inclined to view this as a good improvement. >> >> -mike >> >> On Mon, Sep 22, 2008 at 3:54 PM, Kevin Sutter <[EMAIL PROTECTED]> wrote: >> >> >>> Hi, >>> I've been talking to MikeD about this and I thought I should get some >>> input >>> from other experts... >>> >>> In the EntityListener methods, we can pass an instance of the entity to >>> the >>> method invocation. Is it valid for these methods to update this entity >>> instance? The JPA spec and Pro EJB3 book don't indicate one way or the >>> other. And, all of the examples cited just show read only usage of the >>> entities passed in. The spec is clear that you can't utilize >>> EntityManager >>> and Query operations, but it doesn't qualify what you can or can not do >>> to >>> the entity itself. >>> >>> The specific scenario that I am experiencing is a @PreUpdate method is >>> calling a setter method on one of it's attributes. OpenJPA is getting a >>> little confused with this since this processing is updating the @Version >>> field (when it really doesn't need to). So, the commit rolls back due >>> to >>> inconsistent @Version values. And, due to this update-within-an-update, >>> we >>> end up calling the @PostUpdate listener twice for the same entity >>> instance. >>> Like I said, we get kind of confused. >>> >>> Before I open a JIRA to address this problem, I'm wondering whether >>> anybody >>> is reading the spec differently and this should not be allowed. (BTW, >>> I'm >>> hearing that Hibernate can process this okay, but I have not been able >>> to >>> confirm this.) >>> >>> Comments and discussion welcome. >>> >>> Thanks, >>> Kevin >>> >>> >> >> > > > -- > Simone Gianni CEO Semeru s.r.l. Apache Committer > MALE human being programming a computer http://www.simonegianni.it/ > > > -- View this message in context: http://n2.nabble.com/Updates-to-entities-via-Lifecycle-callback-methods-tp1110631p1113863.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
