[boost] Re: Re: Re: relational table as an STL container --anyinterest?

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-11-01 19:52:57

"Joachim Achtzehnter" <joachim_at_[hidden]> wrote in message
news:Pine.WNT.4.43.0211011536510.163-100000_at_van4.netacquire.com...
> Arkadiy Vertleyb wrote:
> >
> > > [JA:]
> > > Ok. We would probably need to provide a default operator< for tables.
For
> > > efficiency, this might first compare number of rows, and if equal
> > > recursively compare rows and columns.
> >
> > Why?  Do we really need to sort on tables?
>
> There are some reasons why this would be nice.
>
> First of all, for consisteny: If I can create tables of ints, strings,
> etc. without specifying the second template parameter (the "sort order",
> really the primary "key"), then it would seem I should be able to do this
> also when I use a type like a table that the library itself defines.
>
> This really boils down to this argument: The current table implementation
> actually imposes some requirements on the column types rather than truely
> accepting "any type" whatsoever. One of these requiremnts is that the key
> columns (those that are sorted) must be comparable with the std::less
> template function.  It seems to me that if the library requires this, then
> it makes sense for the library's own types to also support this
> requirement. Why should I not be able to use a table as a key?

My main problem with this -- I don't see an intuitive way to compare tables
:o((

> > How was your experience with the library otherwise?
>
> Only did a few very limited trials. In addition to the nested relation
> test, I played with some of the relational operators, like a projection of
> a join with a renamed key column. This worked fine, except that there is
> no escaping the ugly template syntax. Let's face it, in spite of its
> power, the meta-programming capability, which C++ acquired almost by
> accident, is a horrendously ugly programming language.

It becomes better if you concistently allow the compiler's to deduce
template parameters for you, like instead of storing an intermediate object,
you just pass it to a templated function (see the section "let the
compiler..." in the doc).  We may have to define something generic, like
for_each, for this purpose.

Also, in g++, another, more readable, notation for defining type lists could
be used (this would not be a part of the library, so it would not affect the
portability).

Another big problem, however, is when you see a compiler error...  This is a
major area for improvement...

> By the way, one important aspect of a rigorous relational model is that it
> doesn't allow duplicates. The true relational projection operator
> eliminates duplicates. To do this efficiently, in general, may require
> materializing the result?

We have the "distinct" operator, which you can apply to any relation.  Use
it like this:

print(distinct(projection<list<c1, list<c2> > >(my_table)));

By the way, I think this is pretty readable (except the typelist, of
course).

>
> > Have you been able to build the tests?  What compiler are you using?
>
> Have not attempted to build the tests. I was playing with MSVC6 (because I
> was at work, otherwise I'd have used gcc).

OK.  We support both of them.

Arkadiy