...
To revert a sequence of forward (F) LDIFs { F0, F1, F2, F3 } the reverse (R) LDIF operations are applied in the opposite order { R3, R2, R1, R0 }. Some optimizations can be inferred from a sequence to make reverting faster. For example if F0 represents an Add operation and the other changes represent Modify operations on the same entry then only R0 can be applied instead of the R3->R0 sequence of reverse LDIFs. For the time being we just note that these optimizations are possible for implementing reversion capabilities.
| Section |
|---|
| Column |
|---|
 Image Added
|
| 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
| | Column |
|---|
Image Removed
|
Change Stores
| Section |
|---|
| Column |
|---|
Change Stores |
|---|
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 |
|---|
|
|
...
