Hi Denis,

> Is an +Index prefix class required to get a searchable B-Tree
> associated to the relation

Yes. B-Tree are only available in indexes. Entities can, however, also
be searched by other means, i.e. following links from other objects.

> or are these classes just provided for convenience : insuring unicity,
> formatting indexes (keys?) (like +Fold or +Sn)?

Yes. Prefix classes like '+Fold' or '+Sn' format the keys, and determine
the structure of the tree. So, basically, *everything* in the DB
framework is just for convenience, you could theoretically program it
all manually ;)

> Can an +Entity have more than one unique index? Is this advised?

Yes, you can have as many unique or non-unique indexes as you like. It
is perfectly all right to have only a non-unique index. Often there are
also entities which have no index at all (they must be just reachable
via some path of linked symbols from the '*DB' root).

> If the unicity of an +Entity relies on more than one non unique index,
> should they be merged with +Any or +Bag

No. '+Any' or '+Bag' are not useful for this. I think you mean '+Aux'.

> Calling (tree 'relation +EntityClass) provides access to all the
> subclasses of +EntityClass, doesn't it?

This depends on where the 'rel' of that relation is defined. If it is in
the parent class, the index will hold all objects, but if it is in the
subclass, only objects of that subclass will be indexed there.

> Some examples in the html documentation (for +Hook, for example) seem
> to refer to a more complex demo than the one included in picolisp
> distribution : does such a demo exists and is it available?

Most probably there are many cases and combinations of relation
definitions without public examples. Hopefully, there will be more in
the future :)

♪♫ Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to