Re: [boost] Boost.SQL?

Subject: Re: [boost] Boost.SQL?
From: Roland Bock (rbock_at_[hidden])
Date: 2010-09-15 07:46:02

On 09/15/2010 12:02 PM, Mateusz Loskot wrote:
> On 14/09/10 16:38, Roland Bock wrote:
>    
>> On 09/14/2010 04:12 PM, Dominique Devienne wrote:
>>      
>>> A good and established library already mentioned on this list in this
>>> domain ishttp://soci.sourceforge.net/, which uses modern C++ and
>>> Boost.
>>>
>>>        
>> I've seen it. It is certainly one of the best I've seen so far.
>>      
> FYI, the team is applying final changes and new release is coming
> very soon. If you'd like to try it, please check the version from Git
> repo - source code is considered as stable, only floating element is
> build system.
>
> BTW, in case you haven't been aware of this initiative: std::rdb
>
> http://mail-lists.crystalclearsoftware.com/listinfo.cgi/std_rdb-crystalclearsoftware.com
>    
I wasn't aware of that one. Is it in active development? The mailing 
list looks a bit forsaken.
> I'm keenly tracking this thread, looking forward to seeing new SQL ideas.
>
>    
OK, taking the first example from the SOCI project page:

// ---------------------------------------------------
sql<<  "select name, salary from persons where id ="<<  id,
        into(name), into(salary);
// ---------------------------------------------------

This is nice, but still requires attention where the compiler could 
help, if the table definition was known. Here is what it would look like 
in my version (assuming that I manage the transition to boost proto):

// ---------------------------------------------------
typedef table_persons<> persons;
typedef select_record<persons, persons::name, persons::salary> record;

vector<record> records = db.query()
<< select<record>()
<< where(t::id() == id);
do_something(records.front().name_, records.front().salary_);
// ---------------------------------------------------

Here are the pros and cons of my approach that I am aware of

    * CON: It requires the compiler to have intimate knowledge of the
      table definition and you don't want to manually manage changes in
      the C++ table definition (even though it is not too ugly). Thus,
      some code generator is required in the build process.
    * CON: If you want to use nested selects, you would have to define
      "pseudo table classes" to use them (at least that is my current
      concept for that). Up to now, I cannot think of a way to do all
      the type-checking and named value provision without that.
    * PRO: No typo within a string like "select name, salary from
      persons where id = " will pass the compiler.
    * PRO: There is no chance that you mismatch the order of retrieved
      columns, e.g. into(salary), into(name). In this simple example,
      such an error is unlikely, but if you have, say, ten elements?

Maybe it would make sense to add such a layer as an option to SOCI?

Regards,

Roland