Re: [boost] [rdb] 0.04

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?
> http://dtemplatelib.sourceforge.net/
>   
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

J-L