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

11 Nov 2013

      On 2013-11-11 22:22, Edward Diener wrote:
...
On 11/11/2013 10:01 AM, Roland Bock 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  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::vectorstd::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
On 2013-11-11 15:36, Edward Diener wrote:
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::verbatimsqlpp::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