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

Subject: Re: [boost] quince: queries in C++ expressions
From: Roland Bock (rbock_at_[hidden])
Date: 2014-07-17 08:48:09

On 2014-07-17 13:11, Michael Shepanski wrote:
> On 17/07/2014 5:09 PM, Roland Bock wrote:
>> It is really fascinating to see that many ideas are almost identical.
>> sqlpp11 also has a grouping some columns and give the group a name. It
>> is called multi_column, can be accessed by name just like columns and is
>> of course of great value in joins :-)
>
> The difference, of course, is that in quince we don't speak of
> "columns" so much.  :)
:-)
>
> Every query produces values of its "value type", which can be any type
> in this taxonomy:
> http://quince-lib.com/mapped_data_types.html#mapped_data_types.definition_taxonomy
> . It is common for a query's value type to be the same as a table's
> value type, but this is not the case for queries that use join() or
> select().
Shouldn't collections be mentioned on that page, too?
 
>
>
>>> 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.
>> Got it :-)
>>
>> Does quince support adding columns at runtime, btw? Say, I have a table
>> that contains some meta data and a blob. I always want to select the
>> meta data, but whether or not to select the blob is decided at runtime.
>
> Sure. Quince's select() is analogous to supplying an SQL "select
> list". (I say "analogous", not identical, because here again we work
> at the level of C++ types, without regard to whether they are
> single-column or multi-column.)
>
> So it's:
>
>     struct something {
>         metadata meta;  // metadata is some mapped type defined elsewhere
>         vector<uint8_t> blob;
>         string other;
>     };
>     QUINCE_MAP_CLASS(something, (meta)(blob)(other))
>
>     extern table<something> somethings;
>
>     // retrieve metadata only:
>     for (const metadata &m: somethings.select(somethings->meta))
>          // ...
>
>     // retrieve all three parts:
>     for (const something &s: somethings)
>         // ...
>
>     // retrieve metadata and blob only:
>     for (const std::tuple<meta, vector<uint8_t>> &pair:
> somethings.select(somethings->meta, somethings->blob))
>         // ...
>
> In the last example, we could use a collector class if we don't like
> tuples.

Hmm. I guess my question was unclear or I misunderstood you answer.

I was thinking something like

auto query = somethings.select(somethings->meta)
if (userWantsBlob)
   query.add_to_select_list(somethings-blob);
for(const auto& row : query)
{
   if (userWantsBlob)
   {
      //somehow access blob here
   }
}

We have some code in our company that has several of these dynamic
fields. Multiplying the code is not really an option then.

>
>> Since you have watched the "selected template toffees" video, you have
>> seen all the tools already. Here's a walk through:
>>
>>    * You have an expression tree and a context type. The latter is
>>      provided by the database
>>    * sqlpp11 provides a template function called serialize, which takes
>>      an generic expression tree and a generic context (basically any
>>      output stream).
>>    * sqlpp11 also provides "partial specializations" of these functions
>>      via a serializer template class. The partial specializations are
>>      available for all building blocks of the EDSL (e.g. tables,
>> columns,
>>      select, where, arithmetic expressions, ...) and the generic
>> context.
>>      You can see those at the bottom of each header file for such a
>>      building block, e.g.
>>     
>> https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/group_by.h
>>    * If you need special behavior, you add a specialization for the
>>      respective building block and your own context type.
>>    * If your special behavior is that you do not support that feature,
>>      you just say so in a static_assert which fires when the serializer
>>      is instantiate
>>
>>
>> Here's an example from
>> https://github.com/rbock/sqlpp11-connector-sqlite3/blob/master/include/sqlpp11/sqlite3/serializer.h
>>
>> (sqlite does not support full outer join):
>>
>> template<typename Lhs, typename Rhs, typename On>
>> struct serializer_t<sqlite3::serializer_t, join_t<outer_join_t, Lhs,
>> Rhs, On>>
>> {
>> using T = join_t<outer_join_t, Lhs, Rhs, On>;
>> static void _(const T& t, sqlite3::serializer_t& context)
>> {
>> static_assert(::sqlpp::wrong_t<outer_join_t, Lhs, Rhs, On>::value, "No
>> support for outer join");
>> }
>> };
>
> Okay, I think I understand.  When you have a complex expression tree
> that includes, say, a full join somewhere deep inside, then that
> affects the static type of the expression tree as a whole. Therefore,
> when you ask a connector to serialize the tree, the compiler can see
> the incompatibility and fail. Yes?
That's correct for queries with a static structure. For dynamic parts
(like the optional blob in the example above), the compatibility would
be tested when the dynamic part is added to the query.
>
> If so, then it confirms what I suspected (albeit for different
> reasons): I can't make quince behave this way -- or at least the price
> of doing so would be very high.  A complex quince::query object may
> have a full join buried somewhere inside, but it doesn't affect the
> object's static type. (It only becomes apparent when quince tries to
> generate the SQL, so it traverses the tree, calling virtual methods,
> etc.)
If you knew the database type while constructing the query, you could do
those tests during construction. It probably wouldn't even be that hard
with a similar mechanism as used in sqlpp11 (easy for me to say, still
not knowing really much about your code).

Best,

Roland