...
It creates a AddEntryOperation object, with a ADD_ENTRY operation type (how useful is it, considering that we are already defined a specific class for such an operation ???), an entry and a CSN.
The newly created entry will contain two new AttributeType :
- an entryUUID with a newly generated UUID
- an entryDeleted set to FALSE
If the added entry already exists in the current server, then we should consider that the entry can't be added.
...
| Note |
|---|
As we may receive a Add request from a remote server - per replication activation -, we currently create so called glue-entries. There are necessary if we consider that an entry is added when the underlaying tree is absent. It does not make a lot of sense either, because the tree have necessarily been created on the remote server, and the associated created entries have already been transmitted to the local server, thus we don't have to create a glue entry. |
Delete operation
It creates a CompositeOperation object, which contains a ReplaceAttributeOperation, as the entry is not deleted, but instead a entryDeleted AttributeType is added to the entry, and a ReplaceAttributeOperation containing the injection of a entryCSN AttributeType, with a newly created CSN.
So here are the operation content :
- ReplaceAttributeOperation
- entryDeleted, value TRUE
- ReplaceAttributeOperation
- entryCSN, with a new CSN
| Note |
|---|
The delete operation should be a simple attribute Modification. Currently, two requests are sent to the backend (one for each added attribute), which is useless. |