[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Auto-Increment

Howard Chu wrote:
>>Jon Roberts wrote:

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