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