multi-indexed tdb

[simo]

On Sat, 2006-08-05 at 19:30 +0200, Volker Lendecke wrote:
> On Sat, Aug 05, 2006 at 07:21:30PM +0200, Stefan (metze) Metzmacher wrote:
> > is there a reason why you only allow strings (char *) instead of
> > TDB_DATA keys for the indexes?
> 
> No, no specific reason. But in the past we've had issues
> with binary compatibility more than once, and having only
> strings from my point of view is one way to get around these
> problems. That together with easier debuggability. tdbdump
> makes a lot more sense if you can look at strings instead of
> binary blobs.

Hi Volker,
I was reading your code and was thinking that the way you made it you
allow only unique keys.

In some cases this is desirable, like when you want to uniquely link
SIDs, names and UIDs/GIDs together. You do not want to have the same
name or the same UID linked to more than one SID.

In other cases it may be really interesting to have something that
resembles an index instead, where a single secondary key can link
multiple primary keys.

As the primary Key is not directly accessible outside the interface we
can make sure it have a fixed length, so that you can easily extract
multiple keys from the data, based just on the length of the data
segment of a secondary key.

To obtain unique indexing we can also have 2 kind of keys with prefixes
like MULTIKEY and UNIQUEKEY instead of just KEY.
When you want that any secondary key can reference only one primary key
you use UNIQUEKEY as prefix and return an error if someone tries to add
another primary key. When MULTIKEY is used instead adding multiple
primary keys is allowed.

What do you think?


Another question is why do you use a numeric index instead of just
another char prefix?
I think that something like KEY/USER/BLAH is more readable then
KEY/1/BLAH


Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org