Page History

So the whole point to this exercise was to clearly define what we need to track for a change. Obviously we need a unique auto incrementing synchronized sequence to pull new revision numbers from. This will be used for the revision of a change. Each revision has a change associated with it. Here's a list of what needs to be tracked for each change:

• Revision Number: number assigned to the new state of the server once the change is applied
• Forward LDIF: the LDIF applied to switch from S0->S1 (rev0->rev1)
• Reverse LDIF the LDIF applied to revert from S1->S0 (rev1->rev0)
• Change Timestamp: the time the change occured (GMT)
• Principal: the distinguished name of the authorized user that made the change

There are different levels to which we can implement this feature. I think we should enable different pluggable implementations for the change log service to expose different levels of functionality. To enable this we have to design a few different interfaces for the service and it's subcomponents. The following levels of functionality should be possible:

• Basic Change Log: logs changes only (no snapshots)
• Searchable Change Log: logs changes and allows searching on changes
• Taggable Change Log: allows tagging for snapshots
• Searchable and Taggable Change Log: allows tagging and taking snapshots with search capabilities

The same change log logic can be used to swap out different components of a log store to provide varying capabilities and still apply tags and changes to the store interface. Let's take a look at some of the store interfaces which really act as an SPI for this subsystem.

There are 4 kinds of stores represented:

• ChangeLogStore: the simplest kind of change log store that can be implemented (just for logging)
  • Primary method is

    Code Block
    long log( Principal dn, Entry forward, Entry reverse )

  • Another method exists to get the current revision number (should be published in RootDSE perhaps)
• TaggableChangeLogStore: this store allows for tagging for snapshots
  • Two tag() methods exist one which generates a tag on the current revision another on a revision in the past
• SearchableChangeLogStore: a simple store which exposes access to a search engine over change log events
• SearchableTaggableLogStore: a taggable log store which enables searching over changes and tags