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 <mgentr..asslight.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_schmidt7..ahoo.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.
>>
>>
>
This archive was generated by hypermail 2.0.0 : Wed Apr 22 2009 - 12:38:12 EDT