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:
>>>>> 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
>>>> 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
>> 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");
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
* 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk