directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: [core] Loading stored-procedures and setting triggers
Date Fri, 16 Mar 2007 19:59:01 GMT
On 3/16/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> Hi, Directory developers,

Hi,

> 1)  Has anyone given any thought to where we would put the
> initialization code for administrative triggers and stored
> procedure's?
>
> For review, in the ITest there are 2 key lines:
>
>   a)  Where the stored procedure is loaded:
>
> // Load the stored procedure unit which has the stored procedure to be
> triggered.
> JavaStoredProcedureUtils.loadStoredProcedureClass( ctx, BackupUtilities.class );
>
>   b)  Where the trigger is added:
>
> // Create the Trigger Specification within a Trigger Subentry.
> createTriggerSubentry( ctx, "triggerSubentry1", "AFTER Delete CALL \""
> + BackupUtilities.class.getName() + ".backupDeleted\" ( $ldapContext
> \"\", $name, $operationPrincipal, $deletedEntry )" );

These two methods are just for easing some tasks frequently used
during working SP and Triggers. Don't consider them THE way to work
with SPs and Triggers.

You do not need to load SP and Triggers during start-up. They are
persisted within the DIT. If ApacheDS one day comes with some SPs
pre-loaded they will be added on the first start-up of server or they
will be in the prepopulated partition. Subsequent SP and Trigger
additions are regular LDAP operations that you can do whenever you
want.

> The use case here is that I would like to automatically derive
> Kerberos keys for users when they modify userPassword.  So, I have an
> SP that I need to load into the DIT and I have a trigger that I need
> to set on the ou=users subtree.  Short term this could be added to
> ServerContextFactory, after the backend is started and any LDIF's
> loaded.  We could potentially have a lot of them for various
> server/admin tasks.
>
> 2)  Also, what would the process look like for checking if the SP and
> trigger already exist?  Would we just load/set them again since it's
> not harmful, like we do with loading LDIF's at startup?

They exist where you store them. They are currently just raw entries.
They do not know they are SPs and Triggers, they are not handled in a
special way. So just do a search/lookup for them.

> 3)  What are the pros/cons with doing this with a trigger/SP vs. an
> Interceptor?  The major thing is the "scope," right?  Meaning a
> trigger/SP can apply to subtree/subtree refinements (TEDs), while an
> interceptor wouldn't have those semantics by default.  Any other
> pros/cons?

Well, you can still work with scopes with Interceptors. In fact, as
we're developing the core, we do not have to use SPs or Triggers for
core functionality. It may be better to use Interceoptors. SPs and
Triggers are more likely to be used by regular (administrator) users.
One advantage of them is that they are completely user space
constructs and are loaded and managed over LDAP; no need to touch
server side code.

> Enrique

BTW, I plan to work on these two stuff and their documentation this
weekend so I suggest you stay tuned.

HTH,
Thanks.

-- 
Ersin

Mime
View raw message