Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <1092286154.1227743324279.JavaMail.jira@brutus>
Date: Wed, 26 Nov 2008 15:48:44 -0800 (PST)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIRSERVER-1231) Some operation can't be reverted
 with a single reverseLdif element
In-Reply-To: <99551282.1218839984337.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.