Trustin Lee wrote:
On 11/7/06, *Alex Karasulu* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
