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.

Lorenzo Pastrana writes:

On Thu, 2008-12-18 at 14:32 +0100, Hallvard B Furuseth wrote:

...

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 just copy the 'HEAD' entry to a versionned RDN and increment the counter ... This one will be my choice.

Wel, if you copy first and increment after, you can't use the 'unique' overlay to prevent HEAD from having same version as a versioned entry. But if that doesn't worry you, then yes that'd be simpler.

Hallvard B Furuseth wrote:

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:-)

Heh, that's an easy trap to fall into. "Surely this thing is useful for *something*" No, it's not.

NameAndOptionalUID is only usable for referencing a specific entry from within an attribute of another entry. It is *not* usable for *naming* an entry.

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.

The UID part of NameAndOptionalUID *must* be the value of the x500UniqueID attribute of the referenced entry; you don't get to choose some other identifier for the purpose. You'll have to invent some other syntax for a NameAndUUID type...