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