Re: [boost] [rdb] 0.04

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

Am Monday 21 September 2009 23:03:34 schrieb Jean-Louis Leroy:

> >  please also consider an
> > interface that allows you to dynamically define tables.
> > your table definitions seem to rely on the static c++ type system right
> > now, using mpl and fusion. an object relational mapper based on
> > boost.serialization needs to be able to create tables on demand and also
> > insert columns on demand, as a serialize() function can omit fields.
>
> Serialization deals with types purely at compile-time. So it would not
> have problems with the static approach my library is taking.

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.
(pseudo-code, real code would have to use nvp's to match values to columns)

> If you want both dynamic and static mechanisms in the same library,
> there is a choice between wrapping a dynamic system in typesafe
> constructs (at a cost in efficiency but type safety is regained) and
> wrapping a typesafe system in dynamic constructs. But I am not sure that
> the same library should support both. It's certainly feasible but will
> it look better than two separate libs ? The argument can be extended to
> object-relational mappers, except that there is a lot more intelligence
> in them that may make the "one lib" approach more appropriate.

I think it should be in one lib. (static and dynamic I mean, not rdb access in 
general and object-relational mapping).
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?)