Brown Diego wrote: > 2009/3/21 Noriko Hosoi <nhosoi at redhat.com <mailto:nhosoi at redhat.com>> > > This is the restriction the current FDS has. Please see "2.4.2.1. A > Note on Renaming Entries" on this Administration Guide page. > > http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Creating_Directory_Entries-LDIF_Update_Statements.html#LDIF_Update_Statements-Renaming_an_Entry_Using_LDIF > It says really there is no way to move subtrees to different parent. > Instead I need to create same entry with same attributes under the > parent suffix to which I need to actually move it and finally delete the > old ones? Yes. Unfortunately setting the newSuperior in ModifyDNRequest is not supported in FDS even when moving entries without subordinate entries. Having to add/delete an entry to move it is not atomic. So the LDAP client application has to implement some sort of rollback in case something is going wrong. I thought of supporting something like this in web2ldap. But I wonder which order of the operations is right and how to deal with errors. E.g. if there's a unique constraint on some of the attributes an add-delete-sequence will simply fail. And if implementing it as delete-add-sequence and there's something going wrong when adding the entry (e.g. newrdn is already present under the newSuperior) the entry is lost (and has to be re-added at the old superior). Gee, that's bad and probably not worth the implementation effort. FDS developers should seriously consider to at least implement handling the newSuperior in ModifyDNRequest for moving entries without subordinate entries. Ciao, Michael.
