David Boreham wrote:
Hi, just a voice from the trenches, having done this a few times and
made some mistakes:
Do not invent a new kind of database for the change log. Instead use
the one you already have
for entries, with some appropriate indexing enhancements to support
the change log semantics required.
i.e. each change log record is in fact an entry. (there may be a way
to do it where the change log
data is actually stored in the entries themselves, and absolutely no
additional records are
required, but this seems to take an extra high level of cunning to
pull off).
That's an interesting idea. Why should we store twice what we already
have in the backend, if the modification has successfully been applied ?
Now, how do we deal with deletes, and modifications, that's another story.
We are thinking about storing the LDAP request into the CL, not the
entire entry, and we also want to store the controls. At some point, to
avoid useless encoding/decoing, we also thought about storing the PDU only.
If you mean that we should store all the modifications into the backend,
as if they were standard LDAP entries, sure, we can. We just have to
bypass many of the internal logic (like schema checking and such). We
are not that far in the implementation right now :)
But, please don't make work for yourself by doubling the kinds of
database you have.
Two databases also makes it hard to ensure transactional integrity
between the main
db and the change log (which is important to have).
We don't have transaction integrity anyway :) But yes, we need to
guarantee that an operation taht failed is marked as such in the CL, and
that a successful operation is also tagged as such in the CL. Everything
in between is just bad.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
