...
Section |
---|
Column |
---|
|
Column |
---|
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
|
|
The following page present the way reverse LDIF are generated : Generating reverse LDIF
Change Stores
Section |
---|
Column |
---|
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
|
Column |
---|
|
|
...
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