Ersin, Mark,
Alex may have some ideas about using Stored Procedures for better use
cases in the future.
Before discussing use cases for stored procedures which in my opinion
can be infinite let me describe my view of stored procedures in LDAP as
they relate to extended operations.
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.
Stored procedures allow our users to do what they like within the
server. It's not so important to figure out what these use cases are
(although I can list a few that I personally would like to use them
for). What's important is how we expose these procedures through the
protocol while remaining compliant/compatible. Extended operations are
a natural way to expose such operations.
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.
Now here's some of the use cases I am personally interested in:
o House keeping operations (this list is huge but for example
rebuilding indices)
o Management operations (ok so is this one but again for example
mounting a new partition on a namingContext)
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.
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.
Many things can be done with SPs. The sky is the limit or your
imagination. We'll see all sorts of use cases emerge.
Alex
