Boost logo

Boost :

Subject: Re: [boost] [rdb] 0.04
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2009-09-21 17:03:34

Stefan Strasser wrote:
> I only had a short look at your rdb code so far, as most of it is SQL syntax
> sugar and although that looks good that's not the most interesting part of a
> boost db layer for me.
The sql composition feature of my lib may be the tree that hides the
forest. What matters is that it's typesafe and also more efficient. If
the compiler does its job well ther will be no time penalty compared to
hand-written code.
> if you plan to develop this until a boost review
Indeed ;-)

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

Now I reckon that dynamic interaction is useful. You need to be able to
implement Access after all ;-).

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.

At some point I will probably try the second approach though. I have
ideas about it. Some about code (wrapping both fusion:: and std::
vectors and algorithms in a general static/dynamic abstraction), some
about design (does one really need SQL composition in such tool anyway ?
Writing SQL directly will always be easier, even if I'm putting a lot of
effort in making the C++ emulation of the SQL inobstrusive).

> I was planning to include a proof-of-concept object-relational-mapper in my
> object persistence library, using SQLite.
Actually I wanted to implement an orm in the style of my former work
Tangram but I got sidetracked by the persisting lack of a boost rdb lib.
The big problem with Tangram is that it is *too* dynamic : it took one
virtual function call per member variable. I'd like to reduce it to one
per table but it will be more static. Typically it will use Mirror
meta-classes to achieve that.

> eventually this should be based upon a boost database layer like rdb, but it
> seems a little early on to use it already. but please keep me updated on any
> progress
I'll keep posting here and uploading to the vault frequently.

> do you know dtemplatelib?
I had a look at it a long time ago. It's certainly a useful system of
the dynamic type.

Anyway, thanks to all for the feedback


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