That sentence was a garbage I forgot to clean up.  Again, please ignore. ;)


On 11/8/06, Alex Karasulu <> wrote:
Trustin Lee wrote:
> On 11/7/06, *Alex Karasulu* <
> <>> 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:


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


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?


what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6