...
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 :
...
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 :
| Code Blocknoformat |
|---|
* read the entry to be deleted * create a revert ldif AddRequest with this deleted entry * delete the entry |
| Note |
|---|
There is still a question regarding the operational attributes : should we keep them ? How de we guarantee that the creatorName 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... |
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.