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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
