On Mon, Jan 26, 2009 at 11:19 AM, Emmanuel Lecharny <[email protected]>wrote:
> On Mon, Jan 26, 2009 at 4:55 PM, Alex Karasulu <[email protected]> > wrote: > > > > > > On Sun, Jan 25, 2009 at 3:54 PM, Emmanuel Lecharny <[email protected]> > > wrote: > >> > >> Hi guys, > >> - it stores forward and revert changes (we don't need revert usually) > > > > We do need information to be able to revert operations such as deletes > with > > the appropriate add operation. I don't recommend removing the reverse > > changes unless you're certain you can capture all the necessary > information > > to fully revert an operation. > > I was talking about separating the ChangeLog facility from the > Journal, where you don't need revert operations. But obviously, the > ChangeLog needs them. > Right. > > It's interesting to separate those two functions to allow users to > keep what they really need, and remove what they don't need. What we > can do to improve the performance however is to get the forward LDIF > from the ChangeLog (we just have to put them in the context), if the > changelog interceptor is active. > > >> Nothing complicated though. My idea is to use a simple file, being > rotated > >> when we put some tag, plus some JDBM index around to be able to lookup > for > >> DN, UUID or entryCSN. > > > > Why do that when you can build the entire thing using JDBM? > > Just because I think it's easier to recover from a crashed LDIF file > than from a crashed JDBM file :) > Good point. However as you said we might want a separate journal using something howl or the alternative that David Jencks pointed out being using by the AMQ folks. Alex
