Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk