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 Tue, 08 Jun 2010 08:06:56 GMT
I didn't got answers from that important question :

let's imagine we'll have to do it. Let's be clear here : we're considering option to add that
to OpenJPA and share it back as Open source of course.
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 13:26, Jean-Baptiste BRIAUD -- Novlog wrote:

> 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
View raw message