[boost] Re: Relational tables: Ditto and RTL

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-11-15 06:39:18

"Darryl Green" <green_at_[hidden]> wrote in message
news:50C88F08DFE7D611BB5C0060B0C4DD831426FD_at_WNTX...

> I'm not entirely clear on what this means in practice. If I instantiate an
> operator using a table then add or delete elements from the table, I have
> violated the concept that all relations are constant objects. However,
> according to the (very good) docs all (?) that instantiating an operator
> does is to store references to its parameters (the tables). It is only
when
> I obtain and dereference (?) a relation iterator (using print, or calling
> begin() then dereferencing) that iteration over the tables occurs.

This is true in most cases.  However if you use indexing, instantiating of
such operator involvs building internal table (of iterators or keys) in
needed order.

> If I have tables which are not in fact const must I:
>
> a) Modify the tables and create new relation iterators
> OR
> b) Modify the tables and create new relation operators as well as
iterators
> OR
> c) Create the tables, operators and iterators from scratch whenever a
table
> changes

I think a) is generally expected.  In STL, iterators get invalidated when a
container changes.  In RTL you shold be fine with a) as long as you don't
use indexes.  If you do use indexes, they need to be updated whenever a
table changes.  With our current implementation that would mean going with
b)

This problem has two aspects:

1) We currently don't have the ability to incrementally update an index.
This should be easy to fix.
2) Some events should be broadcasted (probably using observer pattern) from
changing table to all indexes that depend on it, so that indexes are updated
together with the table.  Once this is implemented, you should be fine with
a)  in all cases.

> How concrete is the idea?

About as concrete as the above paragraph :-)

> As a potential user of some form of in-memory
> database that definitely needs relations/views based on multiple tables
and
> that will have insertions and deletions (not necessarily vast numbers of
> them) I'm very interested in this.

We need to better understand your requirements in order to adjust our
priorities.  Up until now, we were more focusing on the algebra than on
updating tables.  Therefore, updating tables is the area that definitly has
a huge room for improvement.

Arkadiy