[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Auto-Increment
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 :)
I should point out that I and others
have posted the uidNumber/unique ID solution to this list multiple times
already. A simple search on "uidNumber" in the archive will turn up the
answer explicitly;
Actually, of the 50 entries it returns, only three in a closed thread
relate to this issue, and the two answers are "can't be done" and a
suggestion similar to the way I'm doing it. More relevant entries can be
found with a simple search on the term "increment", to include my own
description of this algorithm a few months ago, before I wrote it.
I note also that the entries returned on a limit exceeding search are
the oldest instead of newest, and if you try to limit the search to more
than 4 specific months you are guaranteed a "nothing found" response,
regardless if matches are there or not.
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.
Locking a value in memory that is dependent on values in the directory is not
a real solution. You have to work within the directory itself if you really
want a guarantee of uniqueness, or ensure that your single process is the
only avenue of entry to the directory.
For this example, I am in fact making this the only avenue for creating
new comment entries. The starting value *does* come from the directory
itself. 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.
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. Both
your solution and mine preclude adding new entries directly with LDIF
files. 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.
I guess for your project, the latter is true, so no big deal,
Actually, this is mostly a constraint of my infrastructure (a single
production server today) and only comes into play in this one example.
The software for the project proper (LDAPHttp) supports distribution of
tiers in a variety of topologies, including multiple servlet engines
and/or multiple databases.
but then you've essentially turned a system designed
for distributed access into a monolithic embedded database, and if that's all
you wanted in the first place, there's more direct ways to do that.
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.
If I were having entries created from multiple directions, I would
absolutely consider storing the value in the directory. For now, I will
skin the cat my own way and defend it as a viable alternative with the
given caveats. Looking at the archives, I'm definitely not the only one
doing it like this. If the LDAP standard ever supports auto-incrementing
attributes (and I don't mean to imply it should), then we can all change
our processes and benefit.
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.
You won't get flames out of me very easily. All I have is praise.
Jon Roberts
www.mentata.com