That sentence was a garbage I forgot to clean up. Again, please ignore. ;)
Trustin Lee wrote:
> On 11/7/06, *Alex Karasulu* < email@example.com
> <mailto:firstname.lastname@example.org>> 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
> 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?