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. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
