Re: [boost] sqlpp11, 3rd iteration

Subject: Re: [boost] sqlpp11, 3rd iteration
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-08-19 18:34:15

Roland Bock wrote:
> On 2014-08-19 18:56, Adam Wulkiewicz wrote:
>> 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.

The additional traits would be a list of variadic template parameters. 
So if this list contained only one type, e.g. sqlpp::default_traits the 
default traits could be generated e.g. by specializing sqlpp::make_traits<>.
Since it's impossible to define a default argument of a template 
parameters pack (another missing language feature?) it could be 
"simulated" with something like:

template <template <typename> class Name,
           typename Trait0 = default_traits,
           typename... Traits
>
struct column
{
     using traits = make_traits<Trait0, Traits...>;
};

Or all traits could be passed as one list type like MPL sequence or 
someting like that as you wrote below.

> 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.
Do you have in mind the code of the library or user's code?
I expect that the user's code, even not using defaults, would be a lot 
shorter.
But the most important is that the definition of a table would probably 
be more clear, in one place, etc.
Or am I wrong?

>
> 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, ...> {};
With variadic templates the construction of traits out of this would be 
straightforward.
An alternative would be to take additional parameters/traits list as the 
3rd parameter as you wrote below.

Btw, why a column must be aware about a Table?

Can a table also have some traits specified?
I'm asking because then there would be 2 lists that should be passed - 
Members and Traits.

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

Sure, I'm not saying that you should change the design. I'm just sharing 
my thoughts.

> 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'm guessing that the function or ... could be passed as yet another 
trait like:

struct alpha: public column<tab_member, alpha_member, sqlpp::trivial_value<some_generator> >
  

If not passed, a default trivial value would be used.

The best would be to somehow pass a static value in compile-time but 
only integral types could be handled this way. The reference to the 
global external variable of non-integral type could also be passed as a 
template parameter but still it would have to be defined somewhere so it 
wouldn't be convenient.

So some_generator could be a type of default-constructible function 
object or a pointer to function, etc.

Or do someone knows some trick that could be used here?

Regards,
Adam