directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [DRS] thoughts about implementation
Date Wed, 04 Feb 2009 08:06:59 GMT
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

View raw message