Versions Compared

Old Version 7

changes.mady.by.user Alex Karasulu

Saved on

compared with

New Version 8

changes.mady.by.user Alex Karasulu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This document describes design choices made regarding the ChangeLogService.

Protocol Changes

  1. Add the revisions attribute to the apache schema.
  2. Add the Proxied Authorization Control (needed for replay)

Representing Changes (deltas)

...

Section
Column
No Format
# REVISION: 1234
# PRINCIPAL: uid=admin,ou=system
# TIMESTAMP: 200706202342343Z
dn: cn=jane doe,ou=users,ou=system
objectClass: top
objectClass: person
cn: jane doe
sn: doe
Column

The revisions and relative position from tail or head tie together the forward and reverse LDIF. This can be used to selectively extract the changes to revert the server to some state other than the start state where revision = 0. Obviously this is not the most high performance implementation one can have but we're not going to be performing any complex search operations over this data.

Another thing this ChangeLogStore can do is backup the log files after reaching a certain size. I don't recommend doing this since it does not really serve a purpose. All the records are needed for history so you don't want to delete the files anyway. Keeping backups of smaller files just creates the problem of figuring out application order with separate files. It can be done with prefixes listing the start and stop revision numbers in the file name but this is not worth the hassle.

Semantics

...

Also note that if the history is cleared you should be able to start

...

from zero again presuming the start you're in to be the start state: this might be useful for staging changes which does not require the entire history.

Tip
Appending to Compressed Log Files
Appending to Compressed Log Files

The best feature one can add to such an implementation is to store the log files in zipped form and insert new entries into them without having to expand the entire file. This however is the only feature worth adding to such a simple implementation.

A separate file can be used to track snapshots. A simple properties file can be used for this where the key is the revision number for the snapshot tag and the value of the key is the description for the snapshot. This probably will not grow very large at all. Another file can be used to persist the current revision or a pointer could be kept on the head or tail to quickly read the REVISION information in the comments of the last entry added to either the forward or reverse LDIF file.

The change log should be a simple interceptor for the time being and can be configured via Spring or programmatically to be added to the interceptor chain. By default it should be disabled. Users can enable server versioning if they would like by uncommenting the interceptor.

Configuration information may be needed for the following possible settings:

  • Wiki Markup
    changeLogDirectory \[path url] - where to put the changelog files
  • Wiki Markup
    compressChangeLog \[boolean] - whether or not to keep the change log ldif files compressed