...
This request is used to move entries or to rename entries or to move and rename entries. Its counterpart in a ldif file is a 'changetype: moddn' or a 'changetype: modrdn' operation (moddn or modrdn are synonymous).
There are five We will separate the ModifyDN into 3 different cases :
- A simple move operation : we change the superior, the RDN
...
- remains the same
- A rename operation : the RDN is changed
- A move and rename operation : a combinaison of both previous operations
Move operation
This is the simplest one : we change the superior, without changing the entry's attributes nor the RDN
the following entry :
No Format |
---|
cn=test, dc=example, dc=orgobjectClass: personobjectClass: topcn: test
|
will be transformed to the entry
No Format |
---|
cn=test, ou=systemobjectClass: personobjectClass: topcn: test
|
if we change the superior from dc=example,dc=com to ou=system
and the revert operation will be :
No Format |
---|
cn=test, ou=systemchangetype: moddnnewRdn: cn=test deleteoldrdn: 0
newSuperior: dc=example,dc=com
|
Rename operation
It's a bit more complex. We have to take care of multiple value RDN (RDN like cn=small+sn=test) and also to the existing attributes. The deleteOldRdn flag must also be take into account when dealing with the revert operation.
There are five cases :
- we change the RDN, we don't change the superior and we don't delete the old RDN : This is a rename
- we change the RDN, we don't change the superior and we delete the old RDN : This is a rename, with cleaning
- we change the RDN, we change the superior and we don't delete the old RDN : This is a move and rename
- we change the RDN, we change the superior and we delete the old RDN : This is a move and rename, with cleaning
- 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
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
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 To compute the revert operation, we do the opposite :
...
The following table gives an example for each of those cases applied on the initial entry :
No Format |
---|
dn: cn=test, dc=example, dc=com
objectclass: top
objectclass: person
cn: test
sn: This is a test
|
For a.1, the new superior will be 'ou=system', the old RDN will be 'cn=test', the new RDN will be 'cn=joe'
...
initial entries :
No Format |
---|
dn: cn=test, dc=example, dc=com
objectclass: top
objectclass: person
cn: test
sn: This is a test dn: cn=test+gn=small dc=example, dc=com
objectclass: top
objectclass: person
cn: testgn: small
sn: This is a test
|
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'
case | deleteoldrdn | new superior | modifying ldif | resulting entry | reverse ldif |
1 | no | none | dn: cn=test, dc=example, dc=com | dn: cn=joe, dc=example, dc=com | dn: cn=joe, dc=example, dc=com |
2 | no | none | dn: cn=test, dc=example, dc=com | dn: cn=joe+sn=the plumber, | dn: cn=joe+sn=the plumber |
...
, | |||||
3 | |||||
case | deleteoldrdn | new superior | modifying ldif | resulting entry | reverse ldif |
1 | no | none | dn: cn=test, dc=example, dc=com | dn: cn=joe*+sn=this is a test*, dc=example, dc=com | dn: cn=joe, test+sn=this is a test, |
1.2 | no | none | dn: cn=test, dc=example, dc=com | dn: cn=joe+sn=the plumber, dc=example, dc=com | dn: cn=joe+sn=the plumber, dc=example, dc=com |
2 | yes | none | dn: cn=test, dc=example, dc=com | dn: cn=joe, dc=example, dc=com | dn: cn=joe, dc=example, dc=com |
3 | no | ou=system | dn: cn=test, dc=example, dc=org | dn: cn=joe, ou=system | dn: cn=joe, ou=system |
4 | yes | ou=system | dn: cn=test, dc=example, dc=org | dn: cn=joe, ou=system | dn: cn=joe, ou=system |
5 | no | ou=system | dn: cn=test, dc=example, dc=org | dn: cn=test, ou=system | dn: cn=test, ou=system |
...