...
Operation |
AddRequest |
DelRequest |
ModifyRequest |
ModifyDNRequest |
ModifyRDNRequest |
AddRequest
Computing the revert LDIF for an AddRequest is easy : it's a DelRequest where we use the DN of the created entry.
...
We have three kind of modifications : add, delete and replace. They are applied in the order they are found in the Modify request, so the reverse LDIF must store them in reverse order too.
ModifyDNRequest
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 four cases :
- we don't change the superior and we don't delete the old RDN
- we don't change the superior and we delete the old RDN
- we change the superior and we don't delete the old RDN
- we change the superior and we delete the old RDN
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
|
The new superior will be 'ou=system'
the new RDN will be 'cn=joe'
case | deleteoldrdn | new superior | resulting ldif | resulting entry |
1 | no | none | dn: cn=test, dc=example, dc=com | dn: cn=joe, dc=example, dc=com |
1 | yes | none | dn: cn=test, dc=example, dc=com | dn: cn=joe, dc=example, dc=com |
1 | no | dc=example, dc=org | dn: cn=test, dc=example, dc=org | dn: cn=joe, ou=system |
1 | yes | dc=example, dc=org | dn: cn=test, dc=example, dc=org | dn: cn=joe, ou=system |