Hi! I've now looked at your test code and I'm not sure if it really is expected to work. The JPA spec imo isn't very clear about exactly _when_ the @PreUpdate gets called.
From the JPA-2.0 spec: 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 call- backs 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. It also doesn't say whether it will get called if the flush is performed for getting reproducible selects, etc. Also the term 'entity data' caused a lot discussions already. What happens with a EllementCollection or a CascadeType.PERSIST 1:n which is stored in your class? This obviously will render data in a different table. So is this covered by 'entity data' or not? There are lots of details in the JPA spec and not everything works as expected once you leave the simple samples and touch more complicated areas like lazy loading, fetch groups, detached entities, etc… You should for example try to close your EntityManager in your test (forces a detach) and then create a new one afterwards. Of course you are relying on OpenJPA specific code, so you can argue that you don't need portability to other JPA providers at all. But still: it's not even guaranteed within OpenJPA that such subtle behavior will not change. I'm also not sure if it's allowed to create a new entity within the same EntityManager while it is getting committed. I remember that I tried that and got an Exception because you cannot modify the EM while it is in the process of getting committed. But not 100% sure yet (grey cells refuse to find the paragraph in the docs) - Pinaki, you know what I mean and can shed a light on it? txs! Of course it imo IS doable with OpenJPA, but it's definitely not a straight way ;) The StateManager code needs a bit of tweaking anyway. You could take a look at OPENJPA-1873 to get an idea about it ;) I've already debugged into the StateManager stuff a big time and am ready to help out once we know how we'd like to solve this. LieGrue, strub --- On Tue, 7/26/11, Bengt Rodehav <be...@rodehav.com> wrote: > From: Bengt Rodehav <be...@rodehav.com> > Subject: Re: Audit log with OpenJPA > To: users@openjpa.apache.org > Date: Tuesday, July 26, 2011, 11:35 PM > Yes, you're right Pinaki. > > I've attached a test case to the JIRA now. I'm very > interested in your > verdict... > > /Bengt > > 2011/7/26 Pinaki Poddar <ppod...@apache.org> > > > Hi Bengt, > > This thread has grown too lengthy for me to find > where was the @PreUpdate > > code. > > For better convergence, please create a JUnit test and > post it to > > OPENJPA-2030 [1] > > > > > > [1] https://issues.apache.org/jira/browse/OPENJPA-2030 > > > > ----- > > Pinaki Poddar > > Chair, Apache OpenJPA Project > > -- > > View this message in context: > > http://openjpa.208410.n2.nabble.com/Audit-log-with-OpenJPA-tp6557932p6623086.html > > Sent from the OpenJPA Users mailing list archive at > Nabble.com. > > >
