Roland Bock 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
On 2014-08-19 18:56, Adam Wulkiewicz wrote: 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
struct column
{
using traits = make_traits 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 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