You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2008/11/27 00:48:44 UTC
[jira] Commented: (DIRSERVER-1231) Some operation can't be reverted
with a single reverseLdif element
[ https://issues.apache.org/jira/browse/DIRSERVER-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651183#action_12651183 ]
Emmanuel Lecharny commented on DIRSERVER-1231:
----------------------------------------------
90% done. The rename operation has been modified, the move operation has been verified, we just have to finish with the moveAndRename operation (which is just a new parameter to pass to the rename operation).
A new class has been created for this purpose : LdifRevertor.
This page list all the different cases : http://cwiki.apache.org/confluence/display/DIRxSRVx11/Reverse+LDIF
> Some operation can't be reverted with a single reverseLdif element
> ------------------------------------------------------------------
>
> Key: DIRSERVER-1231
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1231
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Assignee: Emmanuel Lecharny
> Fix For: 1.5.5
>
>
> There are some operation which can't be reverted if we create a single LdifEntry. For instance, the following entry :
> dn: cn=test,ou=system
> objectClass: top
> objectClass: person
> cn: test
> sn: test
> on which we apply a modification like a rename where the nex DN will be sn=test+c=us, with a deletion of the oldRDN, the new entry will be :
> dn: sn=test+c=us,ou=system
> objectClass: top
> objectClass: person
> cn: test
> c: us
> The sn: test value has been removed.
> The reverse LDIF will be :
> Entry : sn=test+c=us,ou=system
> Change type is MODRDN
> Delete old RDN : true
> New RDN : cn=test
> but the sn attribute will be removed, as the c one.
> The resultant entry will be :
> dn: cn=test,ou=system
> objectClass: top
> objectClass: person
> cn: test
> which is different from the original one, because the sn attribute has been removed.
> There is no other way than to generate a second modification in order to resuscitate this removed attribute :
> Entry : cn=test,ou=system
> Change type is ADD
> Attributes :
> sn: test
> This is mandatory because the 'deleteOldRdn' flag is applied to _all_ the attributes, which will be all destroyed or kept.
> I think that this should be fixed later, as it's a rare condition.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.