Subject: Re: [boost] sqlpp11: SQL for C++
From: Roland Bock (rbock_at_[hidden])
Date: 2013-11-11 16:51:14
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.
* When used as an expression, verbatim() must represent exactly one
expression.
* All dynamic fields are returned as text representations, implicitly
convertible to std::string
sqlpp11 would still do all the syntax checks, assuming that your
verbatim strings are valid expressions (e.g. correct column names).
Best regards,
Roland
Regards,
Roland