2009/3/21 Michael Ströder <michael@xxxxxxxxxxxx>
Brown Diego wrote:
> 2009/3/21 Noriko Hosoi <nhosoi@xxxxxxxxxx <mailto:nhosoi@xxxxxxxxxx>>
>
> 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.Yes. Unfortunately setting the newSuperior in ModifyDNRequest is not
> 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?
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
