directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: Update about subtree problems
Date Tue, 20 Jul 2010 18:30:10 GMT
Emmanuel Lecharny wrote:
>    On 7/20/10 7:46 PM, Howard Chu wrote:
>> Emmanuel Lecharny wrote:
>>>     Thinking about my previous mail, I may have an idea :
>>> what if we don't store the subentry's DN into the selected entries
>>> operational attributes, but the subentry's entryUUID ? This value
>>> *never* changes, we have an index on it, we can also easily build a
>>> cache for it.
>>> It will solve the problems I mentionned with the move and rename
>>> operations, I think.
>>> thoughts ?
>> Sounds good. Pretty sure that AD uses UUID references everywhere too,
>> for similar reasons.
>> I've suggested a few times in the past that LDAP needs a
>> UUIDAndProvisionalName syntax. The UUID would always be present; the
>> DN may be present but may or may not be correct/up to date. (Of
>> course, it may seem senseless to carry a DN around if it isn't always
>> going to be correct, but the point is to reserve a space to put it for
>> when you do know the correct name, that's all.)
> Funny enough, I was also thinking about a similat solution, but I would
> have named it something like UUIDOrProvisionalName :) So that you can
> store either an UUID or a DN.
> The problem now is that the existing AT subschemaSubentry and
> collectiveAttributeSubentries have a DN syntax... So I had to create two
> new AT to store an UUID.
> May be the RFC 3671/2 need an update ?

I think the general idea, at least for AD, is that it's only an internal 
design feature. From the user perspective, all you see is the DN. Internally, 
you carry the entry UUID and you only look it up in your index when you need 
to return the DN to a client.

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

View raw message