Re: [Boost-users] SQL library with full embedded SQL-syntax

From: Kirit Sælensminde (kirit.saelensminde_at_[hidden])
Date: 2007-03-15 04:16:18

Jeff Garland wrote:
> Dmitri Lyfar wrote:
>> Hi
>> I would like to participate in Google Summer of Code in this year. 
> 
> Great, welcome!  Note, this discussion would probably be better hosted in the 
> development list, so I've cross-posted it there.
> 
>> I  reviewed boost projects for last years and found an interesting project, I 
>> think. If you go to the link below you will see a short description for that 
>> library:
>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer_Of_Code_2006#SQL
>>
>> The goal of this post is to define the main library features, which will be 
>> useful for users.
>> Is that library useful for C++ community?
>> If you are using(or have ever used) similar C++ libraries for work with SQL: 
>> which of features do you want to have? Also I want to notice one of the 
>> biggest beauty of that approach: you can get the compiler to type-check the 
>> SQL-expression, what do you think about that?
> 
> Well, I'll be brutally honest -- I don't think I would go that direction.  We 
> didn't pick a database project last year because a majority of the mentors 
> agreed that the 'dsl-based' approach was more of a toy than reality.  The main 
> reason for this is that in 'real-world' applications queries are often dynamic 
> and must be built at run-time.  So, before we get ahead of ourselves and think 
> about 'sql embedded in C++' we need the basics of getting database access.

Our FOST.3 framework handles SQL generation within C++. There are two 
separate aspects to a library like this. One is the generation of the 
CRUD SQL and the other is generalised queries. We took the view that the 
CRUD operations are important within the C++ so that we can use the SQL 
database as an object store. The generalised queries are less important 
(in our opinion) as they are most easily crafted in SQL and for security 
reasons it is best to have them as stored procedures wherever possible.

As for the schema mappings we start with UML and compile that into the 
relevant C++ code and a database. The C++ code includes some static 
binding information and the database also includes some dynamic binding 
information.

This gives a fair bit of flexibility in that the C++ class used to 
represent a given object in the database is determined by the dynamic 
bindings (which carries no speed penalty as the mapping must be done 
anyway) but once the C++ implementation has been chosen then the static 
bindings take over.

We don't have any public information about the low-level aspects of the 
libraries, but there is some on the higher level aspects supported along 
with some example schemas. We're moving the web server everything sits 
on today, but if anybody's interested I can post a few links after it's 
been done.

Kirit