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