Page History

...

1. we change the RDN, we don't change the superior and we don't delete the old RDN : This is a rename
2. we change the RDN, we don't change the superior and we delete the old RDN : This is a rename, with cleaning
3. we change the RDN, we change the superior and we don't delete the old RDN : This is a move and rename
4. we change the RDN, we change the superior and we delete the old RDN : This is a move and rename, with cleaning
5. we don't change the RDN, we change the superior (: this is a Move operation

We have also a few extra cases for 1 to 4, depending on the RDN composition (ie, wether it's a simple RDN or a composite RDN)

a.1  The initial RDN is simple, so is the target RDN (oldRdn: A, newRdn: B)

a.2 The initial RDN is simple, and the target RDN is composite, but they have different values (oldRdn: A, newRdn: B+C)

a.3 The initial RDN is simple, and the target RDN is composite, but they have overlaping values (oldRdn: A, newRdn: A+B)

a.4 The initial RDN is composite, and the taret RDN is simple, but they have different values (oldRdn: A+B, newRdn: C)

a.5 The initial RDN is composite, and the taret RDN is simple, but they have overlaping values (oldRdn: A+B, newRdn: A)

a.6 Both RDN are composite, but don't overlap (oldRdn: A+B, newRdn: C+D)

a.7 Both RDN are composite, and they overlap (oldRdn: A+B, newRdn: B+C)

All those special cases applies to each of the rename operation. We can use this algorithjm to handle them :

- Create all the attributes which are present in the newRdn but not in the oldRdn

- Suppress all the attributes which are present in the oldRdn but not in the newRdn if the deleteOldRdn flag is true

To compute the revert operation, we do the opposite :

- remove all the attributes which are present in the newRdn but not in the oldRdn

- create all the attributes which are present in the oldRdn but not in the newRdn (if they are already present, it won't be a problem)

In any case, we don't have to take care of the deleteOldRdn flag to compute the revert operation.

The following table gives an example for each of those cases applied on the initial entry :

dn: cn=test, dc=example, dc=com
objectclass: top
objectclass: person
cn: test
sn: This is a test

The For a.1, the new superior will be 'ou=system', the old RDN will be 'cn=test', the new RDN will be 'cn=joe'

For a.1, the new superior will be 'ou=system', the old RDN will be 'cn=test', the new RDN will be 'cn=joe+sn=the plumber'

...

if the newRdn is different from the existing EDNRDN

  then reverseLdif.deleteOldRdn = true
  else reverseLdif.deleteOldRdn = false
if modifyDn.newSuperior not empty 
  then reverseLdif.newSuperior = modifyDn.dn minus the modifyDN.dn.getRDN
reverseLdif.newRdn = modifyDn.dn.getRDN