Re: [boost] [rdb] 0.04

Subject: Re: [boost] [rdb] 0.04
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-09-21 20:56:41

Am Tuesday 22 September 2009 01:03:19 schrieb Jean-Louis Leroy:
> > struct A{
> >   bool have_value;
> >   B b;
> >
> >   void serialize(Ar &ar){
> >     ar & have_value;
> >     if(have_value) ar & b;
> >   }
> > };
> >
> > that's valid serialization code and introduces a new table column at
> > runtime if the object is mapped to a rdb and only objects with
> > !have_value have been serialized so far.
>
> True, fully static approaches will create the column even if it's never
> used.

that means that a user would have to manually define the tables his objects 
should be mapped to.
I don't think that's an acceptable assumption for a boost o-r mapper, because 
the mapping would intrude on all user types, even though it's just another 
way to store an object.
take e.g. the serialization of an STL container. a user has no idea how a STL 
container is serialized. e.g. what is the size()-NVP called? so how can he 
define that column?
the fields in STL containers are at least named the same each time, but how 
can he know the private fields of a type he didn't write?

so an o-r mapper must be able to dynamically create columns, and even remove 
columns, as there can be > 1 NVPs with the same name, so the column has to be 
moved to it's own table and mapped as a 1:n relationship. (STL container 
again)

>
> > how did you plan to represent views generated by a SELECT query? because
> > the query results can contain columns from different tables so you'd have
> > to have a "dynamic" row type anyway. (unless you tried to deduce the row
> > type from the query type?)
>
> Exactly. My `select' construct remembers all the types that were
> presented to it. Constructs like views and subselects will be statically

ok, now I see the benefit of C++ SQL constructs (beyond nicer syntax)