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...
This isn't database vendor specific, but library vendor specific, as I
used this implicit behaviour quite a lot, but it is utterly confusing
when mixed with prepared statements. Explicit is better here.
parameters are to be used as placeholders in the query.
parameter lists are to be used to assign values to these parameters and
forward them to the database.
