hi Emmanuel,
Emmanuel Lecharny wrote:
Hi guys,
it's essential that we have a decent Changelog system in order to be
able to build a reliable server, plus use it for replication eventually.
The currengt changelog system has many advantages :
- it basically works
- it's damn fast
- it can be extended easily
But it also has some drawbacks :
- it currently stores changes info in memory
- it stores forward and revert changes (we don't need revert usually)
- it stores changes in LdifEntry which uses Attributes instead of the
new Entry API
We need to extend the ChangeLog API to get able to handle :
- on disk storage
- Entry instead of Attrinutes
didn't understand this. Atm, the LdifEntry used in changelog holds a ClientEntry
and adds all the attributes to it. You mean to use a ServerEntry here?
- only forward operations
- fast lookup for an entry by its DN, or entryCSN/UUID attributes.
We need to allow duplicates in the DN index, there will be collisions.
How do we access CSN/UUID I think, this JournalInterceptor will be before the
ReplicationInterceptor then we don't have access to CSN. One way would be to
create these values in JournalInterceptor and pass on to ReplicationInterceptor
wdyt?
We may also add a new interceptor for that purpose, namely a
JournalInterceptor.
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.
have started experimenting with a simple RandomAccessFile based Journal
( but the work is quite slow cause of me being lazy ;) )
wdyt ?
thanks for putting the thoughts in ink, have a better understanding now
--
Kiran Ayyagari
