Re: Versioning entries in the DIT

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Hallvard