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

Subject: Re: [boost] sqlpp11: SQL for C++
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-11-11 17:22:40

On 11/11/2013 4:51 PM, Roland Bock wrote:
> On 2013-11-11 22:22, Edward Diener wrote:
>> On 11/11/2013 10:01 AM, Roland Bock wrote:
>>> On 2013-11-11 15:36, Edward Diener wrote:
>>>> On 11/11/2013 7:53 AM, Roland Bock wrote:
>>>>> On 2013-11-11 11:27, Rodrigo Madera wrote:
>>>>>> On Sat, Nov 9, 2013 at 8:03 PM, Roland Bock <rbock_at_[hidden]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Just curious over some points:
>>>>>>
>>>>>> Does it support binary transfers over the wire?
>>>>> The library creates template expression trees for the queries. As of
>>>>> now, the tree is serialized and sent to the database connector when
>>>>> you
>>>>> call
>>>>>
>>>>> db.run(query)
>>>>>
>>>>> Result rows are currently to be returned from the connector's result
>>>>> object as const char**, see database_api/api.h.
>>>>
>>>> You are kidding ? Is std::vector<std::string> too advanced ? Why C++
>>>> programmers are still using C null-terminated strings I will never
>>>> understand.
>>> No kidding. The database client libraries I've used so far are C
>>> libraries yielding char**. That is why the current connector interface
>>> also uses const char**. BTW: These are typically not null-terminated but
>>> are delivered with a size_t* or similar to inform about the length...
>>
>> It is irrelevant what the database client libraries return. If you are
>> designing an intelligent interface for C++ end-users to use I believe
>> you should create a return of data which is converted into some C++
>> data type(s). If the returned data is an array of pointers to
>> something lets have it converted, at compile time or run-time,
>> depending on how your library works, into data which a C++ end-user
>> can understand. I do not view 'char **' as anything I want to deal
>> with in modern C++, no matter what it is supposed to mean.
> I totally agree. And as I wrote in my previous mail, the libraries user
> (or C++ end-user) will not get in touch with it. The mere thought of
> handing out char** to the end user makes me shiver.
>
>>
>> With that said the idea of your library looks very interesting. I have
>> always favored an SQL C++ library as one dealing with SQL syntaxes as
>> templated C++ constructs via a DSEL rather than SQL strings of
>> statements. The only downside to your library is that on-the-fly SQL
>> queries based on run-time analysis of database table structure is
>> impossible with such a design, so that I would suggest you also
>> provide a way of generating an SQL string at run-time as a query, with
>> all syntax checking of the string as an end-user responsibility.
>>
> Actually, you can build the query almost completely at runtime, already.
> There is the verbatim method for instance.
>
> auto s = dynamic_select(db).dynamic_columns().dynamic_from();
> ...
> const auto cake = sqlpp::verbatim<sqlpp::text>("cake");
> s.add_column(cake).add_from(tab_bakery);
>
> for (const auto& row : db.run(s))
> {
>     std::cout << row.at("cake") << std::endl;
> }
>
> At the moment, I can think of the following limitations:
>
>    * You cannot use verbatim() as a table yet, but that extension would
>      be almost trivial.

I am not sure what this means. The end-user has to be able to specify a 
table to be used in a valid SQL query, so a verbatim query must accept a 
table. But I suspect you mean something else.

>    * When used as an expression, verbatim() must represent exactly one
>      expression.

That is fine. There is little need in practical code for creating more 
than one verbatim query and running it in multi-threaded code.

>    * All dynamic fields are returned as text representations, implicitly
>      convertible to std::string

That is fine. Here since the end-user is doing on-the-fly run-time 
creation of queries it should be his responsibility of parsing the 
return data.

>
>
> sqlpp11 would still do all the syntax checks, assuming that your
> verbatim strings are valid expressions (e.g. correct column names).

That would be great if it is not too much work for sqlpp11 ! Even 
without syntax checking for verbatim queries it is a worthwhile feature.