directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [ApacheDS][SP] Stored Procedure Languages
Date Mon, 19 Dec 2005 07:39:02 GMT
Hi MarC, :)

2005/12/14, Marc Boorshtein <>:
> > Extended operations (along with controls as well) have been designed to
> > allow users to expand the LDAP protocol while still maintaining
> > compatibility across v3 servers and clients.  Extended operations are
> > similar to ioctls in device drivers.  When something did not fit into
> > the motif of a character or block device driver then an ioctl was used
> > to handle out of band operations.  For example when you need to eject a
> > tape from a tape drive you use an ioctl because it does not map to the
> > existing entry points for a character device.  So in the same light when
> > we have operations to perform or expose which do not fit the LDAP access
> > model we use controls or extended operations.
> I'm not questioning why extended operations exist, I am asking how the
> apacheds team envisions them being used.  ApacheDS thus var is unique
> among the directory server world.  Its one of the few places where
> people are energetic about directories and when combined with the
> talent and imagination of those working on the codebase some very
> interesting ideas have come about.  I suppose it boils down to are you
> building an enterprise ready directory or an experimentation platform?

We want ApacheDS to grow up to enterprise ready directory, but also we want
its modules are stripped out to be as small as it is considered embeddable.
I don't think these two vision don't conflict to each other.

While there are infinite ways to use nearly any development tool, that
> doesn't mean they weren't designed with specific uses in mind.  Nearly
> every successful tool and service was built with specific uses in
> mind.

Yes, you're right.  I agree. :)

> Extended operations are generally published and specified within RFCs so
> > they will have specific extended operation handlers.  Others will be
> > user defined (via stored procedures) and not necessarily published.  For
> > this case a single extended operation for calling stored procedures will
> > enabling users to effectively create any number of private operations.
> >
> Just because something has an RFC doesn't mean it's used.  Remember
> that the directory doesn't provide value, the applications which use
> it do, and there are very few applications which make use of extended
> operations.

Exactly.  People don't use extended operations often.  But what if users can
define what they can do with extended operations very easily using their
favorite script language?  This will change the way people operate on the

It is just like RDBMS stored procedures.  You can call stored procedures
from your JDBC code, or you can just avoid the use of stored procedures.  I
think it depends on your situation.  I think stored procedures are
especially good for administrators who want to manage their DIT.  Imagine
that you can move too old entries to other partition which is more optimized
for read-only access automatically every night.  (Yes, we have to provide
some scheduler here, or use other existing services not reinventing the

>  o Managing complex referential integrity in concert with triggers.
> > What ever we cannot do using schema structures like dITContentRules,
> > dITStructureRules and nameForms can be managed using these two
> > constructs: triggers and SPs.
> In theory this is possible, in practice I've rarely seen directories
> make use of referential integrity (or if it has, its a management
> nightmare).  I understand the theoretical arguments here.

You're right.  But triggers are very useful for management purpose.  For
example, administrators will want to get notified via an SMS or an e-mail
when an important entry is modified.  This can be done easily by combining
trigger and SP, and lessen the burden of management cost definitely.

>  o To implement complex operations on a large amount of data.  Sometimes
> > its best to not pull entries from the DIT just to massage them and then
> > push them back in.  These bulk operations are ideal for stored
> procedures.
> >
> Not sure I understand this one.  Could you give an example?

We can use collective attributes in some cases, but what we want to change
might be fulfilled only by bulk operations (e.g. partial string replacement)

what we call human nature is actually human habit

View raw message