[Fedora-directory-users] Problem in moving subtree of entries to new parent.

[Andrey Ivanov]

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>