[boost] Relational tables: Ditto and RTL

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-11-15 00:36:13

Hi,

I have to admit that I missed this interesting discussion -- shame on me!
We still have to learn more about Ditto to form our view on how the
libraries should relate to each other.  For now, I would like to clarify
some places in RTL that were subject of this discussion:

> - RTL uses expressions for sorting/filtering whereas Ditto uses functors.

Sorting in RTL is done by indexing.  For example, if there is a relation t
sorted on c1, then "iterator_index<list<c2> >(t)" is the same relation
sorted on c2.  The name "iterator_index" reflects the fact that internally
iterators are used.  The "relation" stands for either a table or an
operator.

Filtering in RTL is implemented as "selection" operator, which accepts a
functor.  There are a few pre-defined functors, which can be combined in
expressions.

> - RTL does not seem to automatically update it's views (or whatever it is
> known as in RTL terminology); when a record is added to a table (or view),
> it is not immediately available in all other views based on that table.

This is true, although we did have an idea to address this in the future.  I
have to admit, at this point this is only an idea.

> - Ditto can stack views as to provide multiple levels of refinement of the
> underlying table.

So can RTL:

iterator_index<list<c1> >(selection_eq(iterator_index<list<c2> >(t),
tuple<list<c2> >(5)));

would sort "t" on c2, find all tuples where c2 = 5, and re-sort it back on
c1.  Any other combination of relational operators is also possible.

> - RTL can mix multiple tables into one singular view, Ditto currently
cannot
> (though the architecture is capable of this).

Right.

> - Ditto can assign events (using callback functors) whenever a record is
> added/changed/deleted and even when other events are triggered.

We can't do this now.  Again there is an idea to address this in the future.

> - Ditto can keep a pointer to a single record by means of a tracker class
> which also plugs into the event mechanism, I don't know if/how RTL handles
> this.

We have iterators.

> RTL seems to want to be an in-memory relational database.

Almost true.  RTL is intended to be a "relational algebra library".  We want
to decouple relational algebra from the table implementation, so that both
in-memory and disk-base implementations are possible and can be used
together.  For now we have only in-memory table implementation.  It may or
may not turn out that only in-memory implementations make sence in this
context.  The idea is, adding new table implementations should be
transparent to the library.

If our solution turnes out to be attractive enough, some people who know
more about data structures than we do, might want to write better table
implementations than one based on sorted vector, that we currently have.
Any such suggestions would be most welcome.

As I said, we need to look in Ditto more closely to form our view on how the
libraries should relate to each other.

Regards,

Arkadiy