[ChangeLog] Do we need a revertAndClean() method ?

[Emmanuel Lecharny <el...@apache.org>]

Hi,

as sugested by Alex, here is a new thread to discuss more specifically
about a special need. First, lest sumarize what we agreed on :

- DirectoryService.revert() method reverts operation on the backend,
and does store into the changeLog every operation needed to revert to
a previous revision (ie, if we have to revert a add operation, we will
log a delete operation into the changeLog file).
- ChangeLog.clear() method (to be written) removes all the logged
operation in the changeLog file up to a revision, a specific tag or
the last tag. The backend remains unchanged

That being said, there is a need for some combined operation doing a
revert _and_ a clear. We can obviously call revert() and then call
clear(), but this lead to some inefficiences as the revert() operation
will add some info into the changeLog file each time it is called.

The idea is to combine those two operation into a single one, named
revertAndClear() which will not only revert the operation into the
backed, but also :
1) avoid writing those reverted revert operation into the changeLog file and
2) remover the initial operations from the changeLog file.

Now, the second point, assuming we want to implement such a method, is
what kind of impact it will have on the current code base. Right now,
I think it impact the way the ChangeLog interceptor is used, as this
is the place where we log infos into the changelog, calling
directoryService.getChangeLog.log( getprincipal(), forward, reverse ).

1) We have to compute the forward operation (it's a copy of the operation)
2) We have to compute a reverse operation
3 and we have to call the log() method.

If we can avoid all this work, just because we don't care logging this
revert operation into the change log, as the clear will anyway remove
them from the changelog, then we need to bypass the interceptor.
Another option is to inject a flag into the OperationContext to tell
the interceptor not to log the info (probably a better option than to
deal with the bypass mechanism which may not survive the next frantic
code reorganization ;)

wdyt ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com