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 (herse.apache.org: domain of aok123@bellsouth.net
 designates 205.152.59.64 as permitted sender)
Message-ID: <4550F9F8.8050805@bellsouth.net>
Date: Tue, 07 Nov 2006 16:26:16 -0500
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Thunderbird 1.5.0.7 (X11/20060922)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [Mitosis] IM Session with Trustin
References: <455003AB.7050802@bellsouth.net>
 <768dcb2e0611062119p4ed62031i812c50280dc8f343@mail.gmail.com>
In-Reply-To: <768dcb2e0611062119p4ed62031i812c50280dc8f343@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Trustin Lee wrote:
> On 11/7/06, *Alex Karasulu* <aok123@bellsouth.net 
> <mailto:aok123@bellsouth.net>> wrote:
> 
>     1). When adding an entry that was already marked entryDeleted true, why
>     does mitosis perform a modify operation on the entry instead?
> 
>     Answer: I don't remember maybe I did it this way because of a lack of
>     knowledge. 
> 
> 
> No, it was to avoid recursive deletion.
> 
>     5). Looks like you have not finished implementing the move operation as
>     is indicated
>     here in OperationFactory line 188 in newMove():
> 
>              if ( !deleteOldRn )
>              {
>                  throw new OperationNotSupportedException( "deleteOldRn must
>     be true." );
>              }
> 
>     Is it that you did not implement this or that it was not possible
>     because of some issue?
> 
> 
> If deleteOldRn is false, the move operation is not a move operation but 
> a copy operation.  

Hmmm I don't know what this means.  Inside ADS the move operation is 
used for when entries are literally moved from one container to another.

So if I have the following entries:

ou=base
ou=A,ou=base
ou=B,ou=base
ou=C,ou=base

A move operation would be needed to place ou=A,ou=base under 
ou=C,ou=base to get the following entry:

ou=A,ou=C,ou=base

This is a move operation.  This is why the arguments are oldName, 
newParentName, newRdn, and deleteOldRdn.  Now a rename operation does 
not change the parent of the object just it's name, but this propagates 
as move's to children.

This means a newly copied entries have to have
> different UUIDs. 

Does moving an entry require a new UUID?

Hmmmm.  Basically renaming of entries is causing an issue and this 
UnsupportedOperationException is being fired.  I cannot rename entries 
as long as this is the way it is.

I'm trying to understand why you're pushing a modifyRn into a move 
operation.  I need to understand your reasons before I can fix it.

Can you provide some more feedback on how to get rename working and what 
should be the default behavior?

Thanks,
Alex