OK, let's imagine we'll have to do it. How will we describe it in OpenJPA ?
Should we have some technical annotation like @NativeTrigger or should we have higher level annotation like @Audit ? The later had been done for Hibernate here : http://www.jboss.org/envers Unfortunately it use lifecycle listener to implement @Audit and I'm talking about database "native" trigger. It could be an annotation attribute @Audit(native=true/false) or @Audit(DBTriggers=true/false). About the database instance creation, I would think about some mappingtool option. From both code we could use the current way OpenJPA code already use to detect database and have some branch in the code (command pattern rather than lots of if) so we could add more database over time. What do you think ? On 5 juin 2010, at 09:21, Jean-Baptiste BRIAUD -- Novlog wrote: > I know what do you mean but I really need to do that from Java like the = > DBA would do in your scenario. > > I would love to do that using annotation with OpenJPA mappingtool. > In fact native query are not portable by nature and also, trigger is = > more static than dynamic like database schema is. > That's why annotation would be more convenient to define triggers in a = > portable manner it should be couple with query to specify what to do = > when trigger is fired. > > Are you aware of a portable way to do that in raw Java before JPA = > integrate that cool idea to do it with mappingtool ? > > On 4 juin 2010, at 13:27, No1UNo wrote: > >> >> 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 >> >
