Re: [boost] sqlpp11: SQL for C++

Subject: Re: [boost] sqlpp11: SQL for C++
From: Abel Sinkovics (abel_at_[hidden])
Date: 2013-11-11 14:35:27

Hi Roland,

On 2013-11-09 23:58, Roland Bock wrote:
> On 2013-11-09 23:03, Michael Marcin wrote:
>> On 11/9/2013 4:03 PM, Roland Bock wrote:
>>> Please let me know your questions/thoughts/suggestions/rants.
>>> Contributions welcome, of course :-)
>>>
>> Could you compare your library with SOCI?
>>
>>
> I consider SOCI to be a string and position based approach, meaning that
> you (as a library user) have to use strings to construct your queries
> and positions to extract results. Here is one of SOCI's introductory
> examples:
>
> // ------------------------
> int id = 17;
> string name;
> int salary;
> sql << "select name, salary from persons where id = " << id,
>         into(name), into(salary);
> // ------------------------
>
>
> In sqlpp11 this would read something like this
>
> // ---------------------
> auto result = db.run(select(persons.name,
> persons.salary).from(persons).where(persons.id == 17));
> if (!result.empty())
> {
>     const auto row = result.front();
>     std::string name = row.name;
>     int salary = row.salary;
> }
> // ---------------------
>
> Notice that there are no strings being used in the sqlpp11 code at all.
> The compiler can see and check the syntax of your query. If you mistype
> anything, or if you compare apples and oranges (e.g. a text column and
> an int), or if you forget the 'from' before the 'where' for instance, it
> will let you know with compile errors.
>
> Also, it is much harder to mix up stuff in the results. Imagine a
> slightly larger list of columns being selected. With SOCI you need to
> keep the "select a, b, c, d" in sync with the into(a), into(b), into(c),
> into(d)
>
> sqlpp11 takes care of this responsibility for you and gives you rows
> with appropriately named and typed member variables. It is much harder
> to use those the wrong way without the compiler yelling at you.
There is a library (Metaparse) which supports creating a string-based 
interface for libraries which is processed at compile-time. It could be 
used to provide a string-based interface. For example instead of this:

auto result = db.run(select(persons.name,
persons.salary).from(persons).where(persons.id == 17));

Your library could have the following interface:

auto result = db.run(QUERY("select name,salary from persons where id=17"));

The string could be parsed by a template metaprogram and the right 
classes could be built out of it. It could provide all the static 
guarantees you have described above.

The documentation of Metaparse is here: 
http://abel.web.elte.hu/mpllibs/metaparse/

You can find examples here:
https://github.com/sabel83/mpllibs/tree/master/libs/metaparse/example

Regards,
   Ábel