Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 209.85.161.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=A/q7nSZPqYomf/dKuJXg3XEEtkWlnXpp9dX/YeQmMlA22uyF5e51sRQeBgj+yXQWHV
         pGS9UGFgmPl3xFqutH+9SEeTqwDJoZv3mNO8beO/2vfaglmUNPvqEcRMwekZb+XJTRl+
         O2NfI1G1cMobjqKVp2fnvG2Nk3vQn5RlxLQfs=
Message-ID: <4C45E2AC.1010008@gmail.com>
Date: Tue, 20 Jul 2010 19:53:48 +0200
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Update about subtree problems
References: <4C44E117.6040509@gmail.com>
 <AANLkTilkPGsvp7FqZbBCoBA3SMl7b7F1WXFINLCLfrLL@mail.gmail.com>
 <4C456914.90405@apache.org> <4C4593DA.5030601@gmail.com>
 <4C45E0EE.7080800@symas.com>
In-Reply-To: <4C45E0EE.7080800@symas.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

  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