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/
