...
This implementation should keep things simple. Two files, forward.ldif, and reverse.ldif should be appended as changes occur. As one might suspect the forward.ldif stores in LDIF format the forward changes and is appended to at the tail of the file. The reverse.ldif file stores the reverse LDIF to revert the forward change and is appended to from the head of the file. This way a set of changes can be applied and reverted using these two files. Additional information such as the revision number, timestamp and the principalDn can be encoded within comments before the LDIF entry using implementation specific keys like the following:
| 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
We need to be able to start the logger, to stop it, to configure it, to select the requests, to select the users, etc. Here are a list of parameters we may want to set :
