I have made a request of this feature some time ago, you can follow its progress and add your comments or requests here : https://bugzilla.redhat.com/show_bug.cgi?id=429005 2009/3/21 Michael Str?der <michael at stroeder.com> > 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. > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20090322/49934c23/attachment.html
