Before this, there could be multiple classes representing multiple id
columns. Now there is one class representing ALL the name "id". Very
important for analyzing potential name clashes.
With this method you can indicate additional tables that might be added
via add_from(). These tables are considered in the add_column, add
where, etc methods.
The serializer has partial specializations for all templates. It is a
good basis if the connector/database requires strings close to the
standard.
The interpreter is unspecialized (and uses a static assert to say so).
It is a good basis if the connector/database requires a different
interpretation, e.g. re-writing the expression tree.
The interpretable_t implements three methods for interpretation:
serializing with the sqlpp::serializer_context, serializing with the
database's serialization context and interpretation with the database's
interpretation context.
Moved member template into name class to utilize the fact the class
aliases are really just aliases.
This makes the code leaner in many cases and less complex for the compiler
(I guess). It also has the benefit, that the field name is available as
string in the result_rows. This might be useful for debugging one day.
It is sufficient to have name and type. There is no need for the result
"to know" what exact expression was used to define the column.
Surprisingly, template alias creates new templates (in contrast to
non-template using, which really just creates an alias of a type).
template<typename T> struct A{};
struct X
{
template<typename T>
using U = A<T>;
};
struct Y
{
template<typename T>
using U = A<T>;
template<>
using U<int> = X;
};
template<template<typename> class X>
struct Z{};
static_assert(std::is_same<X::U<int>, Y::U<int>>::value, "class aliases are really just aliases");
static_assert(not std::is_same<Z<X::U>, Z<Y::U>>::value, "template aliases are new templates");
int main()
{
}
