RE: Auto-Increment

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Jon Roberts [mailto:jon@mentata.com]

> Howard Chu wrote:
>  >>Jon Roberts wrote:
> >>http://www.mentata.com/ldaphttp/examples/gospel/jesusblog.htm
> >
> > While I find your project fascinating,
>
> Thanks. I'll take that as encouragement :)

Definitely!

> > reading RFC2251 "LDAP Modify" will give you the background
> > for what is being done.
>
> Read it, and still wondering.
>
> > I have reposted the URLs for the relevant posts so
> > many times now, I'm just going to leave this as an exercise
> for the reader.
>
> Psst... the answer key:
> http://www.openldap.org/lists/openldap-software/200210/msg00550.html
>
> Reading the posts, this *is* a good idea (regardless of what I may have
> said in the past), although it definitely isn't faster than what I'm
> doing and it's not foolproof.

True. All of your processes that modify the directory must agree to use the
same method, otherwise it fails.

> No matter what you do there is a guarantee of uniqueness: since
> this is the RDN attribute, a new entry with an existing value will be
> rejected by LDAP in all cases.

Fair enough.

> I think it's a bit unfair to say this is "not a real solution", since it
> works fine and has its own advantages. If you store the value in the
> directory, then *every* avenue you use to add data needs to be
> programmed to perform the atomic modification of the max-value.

Yes, but using LDAPModify correctly means that any number of clients can
operate at once. The state that you maintain internally to your single
process is of no value when more than one client is in the picture, so unless
you're sure you'll never want more than one client, it's better not to have
that internal state at all.

> Both
> your solution and mine preclude adding new entries directly with LDIF
> files.

If you mean, we can't just invoke the ldapadd commandline tool all by itself,
sure. But once you've executed the Modify algorithm and obtained a unique ID,
you can add your entry however you wish.

> And what happens if you have to rebuild your database (don't say
> this never happens)? You may have to manually infer the max value as
> part of the process.

Yes. But that is a situation well outside the normal application scenario.
(And as things progress, we hopefully have continued to reduce the number of
times you need to rebuild.)

> A square is a square. A square is also a rectangle. Directory databases
> can be treated as distributed, monolithic, or both simultaneously. It is
> not unreasonable to mandate a single method for creating new entries to
> a directory. Often enough, creation of new data for a given class is a
> single business process, and occasionally it is even handled by a single
> person or department in an organization. However, that doesn't mean that
> once the data is in there it can't be accessed or modified from
> distributed agents and various methods. In my contractual work (which
> I'm not free to discuss in detail), I do this very thing.

Yes. It should be pretty clear that you must mandate a single method,
otherwise there are no guarantees. The difference is that one method works
with any number of active modifiers, where as the other is oriented toward
the single method running in only a single instance. But of course you're
right; very often there is no need or desire to allow more than one entity to
make changes in the first place. I still stand by my previous point - you
can't be sure that someone won't change their mind down the road, and want
multiple access. In that case, the internal state is useless, so it's best
not to have it at all.

> Looking at the archives, I'm definitely not the only one doing it like
this.

This is an argument for mediocrity. In the midst of an excellent post, I find
this position surprising.

> I know what I'm doing is going to be regarded as a bit wierd. With my
> examples, I've been trying to expand developer's perceptions of what
> these tools can be used to accomplish. For the record, the pressure to
> demonstrate a weblog application was coming from the servlet framework
> people. The fact that I can do it as simply as I have is testament to
> the flexibility of LDAP. You may think that an RDBMS should be preferred
> for all such requirements, but I'll argue that you are underestimating
> the ease of use and overall value of your product.

Not weird at all. I do not in any way wish to belittle your work. Your
objective is no different from my own, and at Symas we've done countless
things to/with LDAP to push it where no one thought it should/could go. Many
of those things have trickled into the main source base - back-ldap &
backglue are two obvious ones. (Most are things we don't talk about in
public.) But as often as I find good applications for LDAP, I also find
places where there's no particularly good reason to use it.

At any rate, I'm not questioning your decision here. You obviously have your
goals and constraints well in hand.

> You won't get flames out of me very easily. All I have is praise.

Much appreciated.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support