I seem to remember this coming up in the past and we made a change to only fire a callback event for the owner of the relationship.
That said, I took a look at the OpenJPA doc it's a little fuzzy - relevant section follows: PreUpdate<http://java.sun.com/javaee/6/docs/api/javax/persistence/PreUpdate.html>: Methods marked with this annotation will be invoked just the persistent values in your objects are flushed to the datastore. This is equivalent to the XML element tag pre-update. PreUpdate is the complement to PostLoad . While methods marked with PostLoadare most often used to initialize non-persistent values from persistent data, methods annotated with PreUpdate is normally used to set persistent fields with information cached in non-persistent data. I suppose one could want to store some information about the collection in another persistent field. That use case would require a post load event for both sides of the collection. I haven't looked into the issue enough to have an opinion, but we should document it better (or maybe I need to search the docs better). -mike On Wed, Jan 26, 2011 at 2:08 PM, Mark Struberg <strub...@yahoo.de> wrote: > Hi! > > The spec says (3.5.2): > "The PreUpdate and PostUpdate callbacks occur before and after the database > update operations to entity data respectively." > > Does that mean that @PreUpdate should get called only before any real SQL > update to the database?, or always if the entity got made dirty (but not get > subsequently updated into the database)? > > The phrase in question is "database update operations to entity data". Is > the focus more on 'database' or on 'entity data'? > > > The situation is as following: > > @Entity > @EntityListener(AuditListener.class) > public class Person { > ... > @OneToMany > List<Address> addresses; > ... > > public void addAddress(Address a) { > addresses.add(a); > } > } > > This means that adding an address will render the Person entity dirty and > it will subsequently get flushed. But of course there will be no database > SQL UPDATE Person get executed but only a SQL INSERT ADDRESS... > > Shall the EntityListener on the Person entity really get called in this > case? > > PS: I can live with that, but I'd rather clarify the expected behaviour > before doing my own 'non-collections dirty' detection for the AuditListener > (which sets the modifiedBy and modifiedAt attributes). > > txs and LieGrue, > strub > > > > > > >
