RE: [boost] Re: Relational tables: Ditto and RTL

From: Darryl Green (green_at_[hidden])
Date: 2002-11-17 20:28:06

> -----Original Message-----
> From: Arkadiy Vertleyb [mailto:vertleyb_at_[hidden]] 
> > 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
..
> 
> 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.

Right. So the index would need soe form of insert and delete operators. What
parameter would these take? An iterator to the new/soon to be deleted row in
the table?

> 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.
> 

That doesn't sound too hard either, give or take some lifetime management
issues. For the incremental update facility to be useful it seems as though
this facility should also be implemented.

> 
> > 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.

Please don't pay too much attention to my application - I don't know how
typical it is, and I could probably live with the lib as is. The application
is to add querying/reporting capabilities to a monitoring/supervisory
control system running on an embedded linux platform. Currently, such
reporting is available from a central (periodically updated) SQL database,
but for a number of reasons it would be useful to have similar facilities
available directly from each monitoring device. We would also use the same
mechanism for some core operational functions that are effectively queries
on the data. In the absence of such a library those functions are, or would
be, implemented on an ad-hoc basis. Inserts/deletes are relatively
infrequent (these generally imply a change to the physical configuration of
the system being monitored) but we need them to occur without disruption to
the operation of the system as a whole.

> 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.
> 

I certainly think the emphasis on the algebra is the right one. The
performance hit of rebuilding indexes would be relatively infrequent in my
application, I'd have to progress a bit further with the design to see if
this was a real issue.

Thanks for the clarifications.

Darryl Green.