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

Subject: Re: [boost] quince: queries in C++ expressions
From: Michael Shepanski (mps_at_[hidden])
Date: 2014-07-17 02:04:38

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<std::tuple<cinema,  screen,  movie>>  combinations  =
          join(cinemas,  screens,  movies);

Code that receives the results would look like this:

    for (const std::tuple<cinema, screen, movie> &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/mysql/serializer.h
>
> 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