Mark, Yes, I realize that this is not in accordance with the JPA spec. I was, though, hoping it may be possible to do this with OpenJPA. Pinaki created the JIRA issue OPENJPA-2030 which to me is an indication that he believes that OpenJPA should support audit logging in some way. I think that is the way to go. First make good support for audit logging in OpenJPA, then try to get it into the standard.
Also, to be competitive I think good support for audit logging is a must. I know Hibernate has its own solution for it - haven't checked EclipseLink. Other applications in my company (developed for the .NET platform) have excellent support for this. To my understanding it is kind of built in but I'm not sure about it. I'm not familiar enough with OpenJPA to know how audit logging is best implemented. I can contribute in the are of requirements / wishes. I think OPENJPA-2030 is well formulated but I would like to add a few: - Persistence. Flexible persistence of the audit log (like Pinaki wrote). It does however imply that it must be possible to register an "audit log persistence provider" with OpenJPA and it must be possible to initialize it properly. I'm purely using OSGi these days so I really want to use OSGi services for this. - What to log. Could be only changed values or the whole object. In my case I marked entities to be audit logged with an annotation. I also marked the fields to audit log with another annotation. Some flexibility in this area is much needed. - Format. I was going for JSON but might go back to XML if JSON is not flexible enough.It would be nice to store the whole previous version of an entity together with information about what fields were actually changed. The Hibernate audit logging solution (Envers) I think stores the audit log in separate "shadow tables", i e they don't serialize the entity like I do. I did look a little more on Envers and it's not bad. If OpenJPA had the same functionality I would probably use it. Ideally, storing the audit log in a separate table and being able to retrieve old versions from that table would be supported as one of the ways to persist the audit log entries. The only reason I've gone for serialization is that it doesn't need any database migration. Also, I havent seen any support for retrieving entities from an alternate tabe (the audit log table). However, using the AuditReader in Enverse makes this easy. However, finding out all entities that a certain user has changed is harder if the audit log is spread out in different tables - your mileage might vary... /Bengt 2011/7/27 Mark Struberg <strub...@yahoo.de> > 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. > > > > > >
