openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste BRIAUD -- Novlog <j-b.bri...@novlog.com>
Subject Re: JPA for portable database management (and wishes for JPA 3.0)
Date Sat, 05 Jun 2010 11:26:34 GMT
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
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message