Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at