Howard Chu writes:
Lorenzo Pastrana wrote:
I'm planning to store some 'versioned' data into an ldap directory, and trying not to reinvent the wheel ... if anybody has any good resource to share on the subject I'll be glad to hear.
There's no standard or transparent way to do this. The most straightforward approach is to use a multi-valued RDN for your entries, e.g. instead of cn=foo,o=example use cn=foo+id=1,o=example cn=foo+id=2,o=example and so on.
Except of course, that you can no longer reference entries without knowing their version number.
Also there is no indication of what is the last version of an entry, you'll have to look them all up to find it.
There are plenty of ways to solve that - but with the ones I can think of, creating a new version is not an atomic operation. Maybe someone else has a bright idea.
E.g.:
Keep an entry with administrative info - e.g. an entry can have a sibling which contains the last version number of each of its siblings. Similar to a subdir/.../subdir/CVS/Entries file.
Or store a "last" boolean attribute in one of the entries. Or maybe a DN-valued "last" attribute which contains the DN except the version number, so you can use the 'unique' overlay to ensure only one entry is "last". And you can store other tags than "last" for that matter, similar to CVS tags.
Another variant is to have the last entry with a version attribute but without a version in the RDN. When updating, rename the entry to include the version in the RDN, then copy it to the versionless DN with an incremented version number.
Or use aliases for the "last" version and whatever other tags you need. However, beware that a mass of aliases tend to be a PITA. For one thing, only Search operations follow them. And they ruin the point of an index: Regardless of indexing, a search which follows aliases must follow each alias in scope to see if the aliased entry matches the filter.
Surely an attribute with the Name and Optional UID syntax ought to be useful for this somehow, even if I can't think of how at the moment:-) That is, a DN optionally followed by #<bitstring> used to disambiguate several entries with the same "effective" DN. Maybe combined with an attribute with a copy of entries' entryUUID attribute, and an index on entryUUID. That's a unique ID which OpenLDAP generates for each entry, and which does not change even when the entry is renamed.