Re: [boost] sqlpp11, 3rd iteration

Subject: Re: [boost] sqlpp11, 3rd iteration
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-19 15:34:51

On 2014-08-19 18:56, Adam Wulkiewicz wrote:
> Roland Bock wrote:
>> On 2014-08-19 16:43, Adam Wulkiewicz wrote:
>>> I'm wondering, could it be possible to implement similar, compile-time
>>> interface in sqlpp, e.g. something similar to MPL?
>>> I'm asking because what the sqlpp library requires is very
>>> complicated:https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h
>>> I'm aware that its purpose is to create a type reflecting required
>>> columns and to use them from the level of C++ but couldn't it be done
>>> simpler?
>> The crucial part is the _member_t template. I need that one. The other
>> stuff can be constructed whatever way you like. But if the name of the
>> column is `beta`, then I need a way to get this:
>>
>> template<typename T>
>> struct _member_t
>> {
>>      T beta;
>>      T& operator()() { return beta; }
>>      const T& operator()() const { return beta; }
>> };
>>
>> This is the magic ingredient that makes tables, result rows and
>> parameter sets of prepared statements to have members with a proper
>> name.
>>
>> The way it works is best to be observed in the table_t template, see
>> https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/table.h
>>
>> template<typename Table, typename... ColumnSpec>
>> struct table_t
>>     : public table_base_t,
>>       public ColumnSpec::_name_t
>>        ::template _member_t<column_t<Table, ColumnSpec>>...
>
> Ok AFAIU a struct like _member_t should define some convenient member
> variable for the user and must define operator() for the library.
> But the rest could be automatically generated, couldn't it?
> Why not just pass a list of templates of classes adapted to MemberType
> concept (defined operator()) into the table/column/etc.?
> I'm thinking about something like the code below. I don't know exactly
> what's required so this is just an example of a technique rather than
> a solution ready-to-use in sqlpp.
The idea is good. For the columns, you will have to add a few more
parameters, e.g. the value_type (mandatory), can_be_null,
must_not_insert, must_not_update, null_is_trivial, trivial_is_null,
maybe as per your suggestion a default value or a function for producing
it. That default stuff might be tough in such a design.

But thats manageable. And yes, the code would be shorter, although not
that much, I suspect. The only problem I have with it is that now the
column types are going to be about a hundred characters long. And users
are going to operate on columns all the time. So error message have to
be short.

I would thus add a struct which inherits from the column template
instance for each column, e..g.

struct alpha: public column<tab_member, alpha_member, sqlpp::integral,
sqlpp::tag::must_not_insert, ...> {};

I tried something similar a while back but failed, which is mainly due
to lack of perseverance, I guess.

Right now, I am happy with the current design because it is quite easy
to change things, like introducing that default value or a function for
handling attempts to read NULL.

If you want to put everything into that one list of template parameters,
it is much tougher, IMO. I mean how would you add a function for
handling access to NULL value? You would need another class, I think.
And you would have to group those tags into a tuple or type_set, because
otherwise it would be ugly to add another optional parameter...

[...]
>> I see no way to create such a template other than having it in the code.
>> You should of course not write it personally. You should use macros
>> (yuk) or code generators similar to the ddl2cpp script in the
>> repository. But you have to somehow create this code.
>>
>> Unless you know some brilliant TMP technique for this?
>> Personally I think that is a missing feature in C++. I'd call it named
>> member mixin. Or something like that. Hmm.
>> Or, in addition to names and values, we should be able to declare names
>> in templates. That would be awesome!
>>
>> Anyway, if the name thing can be solved without macros, I am all for a
>> terser notation :-)
>
> Maybe in one of the future standards... :)

Yeah, I should start working on that. I am really quite fascinated by
the idea of having names as template parameters.

Cheers,

Roland