I've done auditing a couple of ways in the past. The first time, in Cayenne 1.1, I did it at the application level using customized entity templates and setAndLog() methods instead of set() methods. It wasn't ideal, and it didn't work for many-to-many joins (never had any many-to-manys back then so it never came up).
In Cayenne 1.2 & 2.0, I used a different model. There's a description of how it was done in this patch: http://issues.apache.org/jira/browse/CAY-414 I never finished isolating the audit-only code for the 2.0 patch mentioned from the left-outer-join code, but you should be able to do so. I would expect it would still work for for 3.0, but I don't know for sure, as my only Cayenne projects these days are maintenance-only 1.1 and 2.0 projects. The 2.0 patch should do what you need, although it expects sequence-generated ids and not autoincrement. I'm not completely certain if that matters. If nothing else, it'll get you started on how you can implement this. You might also take a look at the 3.0 lifecycles that Ari mentioned in the issue, but my guess is that JPA lifecycles won't do what is needed. On Wed, Apr 22, 2009 at 11:25 AM, Michael Gentry <mgen...@masslight.net> wrote: > FWIW, we are planning on filling in our Audit table using triggers on > the tables we care about auditing. This will also capture changes > made outside of Cayenne. > > On Wed, Apr 22, 2009 at 10:53 AM, Joseph Schmidt > <joseph_schmid...@yahoo.com> wrote: >> >>>> I'd be interested in hearing what others have to say... feasible given >>>> the current cayenne stack? >>> >>> The problem is that the original poster is trying to use Cayenne like he >>> uses pure SQL and >> >> No, I'm not. >> Like I mentioned in earlier posts, I'm using ObjRelationships and all the >> Cayenne goodies. Just that for some properties that are not needed/fetched >> by the application itself (but are required for various reasons: legal, >> admin, etc.) those values also must be written inside the same transaction >> in there, so that externals tools/applications can access them in the >> required format (e.g. once a week). >> >> If we take only the Audit part: years ago it was done with stored procedures >> and triggers. Now because the business logic migrated more and more from the >> DB level(to upper more abstract levels), there's not enough info at the low >> trigger level to do it, so the ORM needs to do it - in this case: Cayenne >> if it's possible. >> >>> he hasn't demonstrated how he would even achieve what he wants with pure >>> SQL (hint: LAST_INSERT_ID() is the mysql specific way of getting the last >>> id. His other approaches just don't work. But even LAST_INSERT_ID() would >>> probably create race conditions with multiple concurrent users.) >> >> Of course I demonstrated. The snippet in the parent just works with MySQL >> (with InnoDB of course). >> There's no need for a last_insert_id(), since the PK are "autoincrement". >> Inside the same transaction, the consequent selects will simply pick the >> correct values (generated by autoincrement). This is how MySQL is mostly >> used. >> >>> There is however a solution to relationships or attributes which need to >>> be added to 75% of the tables in the database: inheritance. In this case >>> vertical inheritance is the appropriate choice. We are just now testing the >>> excellent work Andrus has done in this area and we have all the basic parts >>> of inheritance working in ROP. >> >> This sounds interesting. >> >> thanks, >> Joseph. >> >> >
