...
This page describes the way we generate reverse LDIF, for each operationsforward operation. Reverse A reverse LDIF can be applied on a server in order to revert some changes done. The only condition is that an operation.
In this document we do not consider what is required to revert a series of operations which have ordering requirements: i.e. they must be played applied in the exact reverse order.
We should not store a revert LDIF if the operation has failed (for any reason).
Operations
Here we simply focus on how to generate the LDIF for each atomic operation.
Operations
Operations to generate reverse LDIF forHere are the operations we are considering :
Operation |
AddRequest |
DelRequest |
ModifyRequest |
ModifyDNRequest |
AddRequest
Computing the revert reverse LDIF for an AddRequest is easy: it's a DelRequest where we use the DN of the created entry.
...
| No Format |
|---|
dn: cn=test, dc=example, dc=com changetype: delete |
DelRequest
To produce a revert reverse LDIF for a DelRequest, we must first read the deleted attribute. We will create a Add Request AddRequest based on the read deleted entry :
...
| Note |
|---|
There is still a question regarding the operational attributes: should we keep them (in the LDIF)? How de do we guarantee that the creatorName creatorsName and createTimeStamp attributes are the original ones, instead of the one injected while creating the saved entry? We will have some impact on the OperationaAttributesInterceptor..Operational attribute state needs to be captured out of band (from the LDIF data) and is the responsibility of the change log service to manage, capture and track. This information is made available to higher level interfaces which handle all this. So at this level we need not worry: the LDIF's generated have no operational attributes in them as would be normally expected for a valid LDIF. |
To be able to build this reverse ldif, we need to read the previous entry before the deletion.
...