Introduction

This page describes the way we generate reverse LDIF, for each operations. Reverse LDIF can be applied on a server in order to revert some changes done. The only condition is that they must be played in the exact reverse order.

Prerequisite

Each reverse LDIF must contains a revision number which identify uniquely its order : R-ldif-rev.

We should not store a revert LDIF if the operation has failed (for any reason).

Operations

Here are the operations we are considering :

AddRequest

Computing the revert LDIF for an AddRequest is easy : it's a DelRequest where we use the DN of the created entry

DelRequest

To produce a revert LDIF for a DelRequest, we must first read the deleted attribute. We will create a Add Request based on the read deleted entry :

* read the entry to be deleted
* create a revert ldif AddRequest with this deleted entry
* delete the entry

ModifyRequest

This is the most complex operation. The modification is applied on a specific entry, and can impact one or more attribute, one or more value, but it can't modify an attribute which is part iof the entry RDN.

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.