Re: [boost] quince: queries in C++ expressions

On 17/07/2014 2:48 PM, Roland Bock wrote:

The automatic, ever changing alias is a cool feature. Since the actual alias is unknown to the user, that requires the std::get<index> instead of using a name, but that is probably OK for joins.

What you say about std::get<index> makes me think there might be some residual misunderstanding. It's true that joins generate tuples. E.g. (from http://quince-lib.com/queries/join.html): const query> combinations = join(cinemas, screens, movies); Code that receives the results would look like this: for (const std::tuple &combo: combinations) As you can see, the members of the received tuple are a cinema, a screen, and a movie. So the user will say std::get<>(), but it's not to access individual columns. And in any case, if the user doesn't like tuples, he can use a collector class instead (http://quince-lib.com/queries/join/collector.html), then he doesn't need to use std::get<>() in any way at all. All of these points apply the same to normal joins or self-joins. The only difference with self-joins is the use of table_alias objects in lieu of table objects.

Not exactly. In sqlpp11, the database type is only required for serialization/interpretation. If the full statement structure is known at compile time, the statement_t is independent of the database. Only if you use parts which are decided at runtime (e.g. some expensive column X is in the result row only if the user really, reallly wants it), then these dynamic parts require to know the database and it is convenient to do this by adding the database type to the complete statement.

Thus, in at least 90% of the statements I write myself, the database template parameter of the statement is just void.

So, if it's not too much trouble, could you walk through the steps that lead to a compile-time failure, if I try to use a feature that is not supported on the DBMS where I am trying to use it?

Yes, the connector library is completely free, but it does not have to re-invent the wheel, too.

sqlpp11 has a default serializer implementation which generates standard SQL. The connector libraries only have to specialize for the things that are actually special. For instance, MySQL uses the concat function instead of the || operator. Thus it has to specialize string concatenation.

This is the full serializer specialization for the MySQL connector: https://github.com/rbock/sqlpp11-connector-mysql/blob/master/include/sqlpp11...

sqlpp11's EDSL is not complete yet, so there probably will be a few more entries for other special things, for instance iirc, MySQL does not support WITH, so I would disable it in that file by adding a static assert into a specialization for with_t.

Cool. (Btw I saw your online video about "template toffees", and it made me think I should do more with static_assert. My thinking has been "Any error I can catch at compile-time rather than run-time is awesome", but of course earlier is better, even at compile time.) Cheers, --- Michael