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

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 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.

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.