Ok, that sounds weird...
Earlier, each node in the SQL tree had a struct containing all recursive
traits. This is now gone. It only contains a reference to all sub nodes
and its own specific traits.
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.
traits are shorter and easier to identify by using tags in a variadic
template
recursive traits can be automatically derived, which makes it much
easier to add new traits to be handed through the expression tree.
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.
The code is much easier to read, the optimizer should take care of
pretty much everything, AND it copiles even faster without the code
being riddled with std::forward and std::decay
This namespace is for things the developer will not get in touch with
(normally) but the vendor might need to use for specialization of the
interpreter.
This separation is not fully completed yet, some changes will have to
follow...
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.
rbock