Security teams are, in my experience, much more comfortable with database triggers for auditing purposes. If you are writing records into a audit_log on each operation, this will not interfere with JPA. That you require it to be operational from any method of data access would seem to confirm implementation on the DB side.
Generally, I would expect the triggers to be installed and locked down from a secure database account (i.e. not the one used by the JPA application). As such, I would expect the table creation and trigger installation to be performed by the DBA prior to executing the JPA application. In the unlikely event that it is acceptable to install the triggers from the JPA side, you could do this using native queries. -=- Jerry On Jun 4, 2010, at 4:09 AM, Jean-Baptiste BRIAUD -- Novlog [via OpenJPA] wrote: > Unfortunately, lifecycle in JPA will not answer to the direct need of "that" > triggers. > I need triggers because our customer asked for *secure* audit trail. > That audit trail must be operational for any data access, from or not from > the Java application server. > That must be done very strictly for legal purpose, so it can't be any Java > part at runtime. > > So, I was only thinking about a "installation time" (creating the triggers) > written in Java so it will be portable. > As we are not just doing project for customers, I would like to to that in a > portable manner. > > If not OpenJPA, are you aware of any framework that would allow portable DDL > statement in Java ? > > View message @ > http://openjpa.208410.n2.nabble.com/JPA-for-portable-database-management-tp5134215p5138491.html > > To start a new topic under OpenJPA Users, email > ml-node+208411-1595610943-93...@n2.nabble.com > To unsubscribe from OpenJPA Users, click here. > -- View this message in context: http://openjpa.208410.n2.nabble.com/JPA-for-portable-database-management-tp5134215p5139037.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
