const float max_radius = 100.0f; const exprn_mapper<float> x_distance = cinemas->location.x - my_place.x; const exprn_mapper<float> y_distance = cinemas->location.y - my_place.y; const predicate within_radius = x_distance*x_distance + y_distance*y_distance <= max_radius*max_radius;
Here we construct three
exprn_mapper. The type
predicate is a typedef
exprn_mapper is an object
that quince is able to translate into an SQL expression.
As we shall see, the variety of contexts in which you can use
exprn_mappers in quince is about the
same as the variety of contexts in which you use SQL expressions in SQL.
And the purpose is the same: to get computations done on the DBMS's side.
parameter specifies its return type. That is the C++
equivalent of the SQL expression's return type, which has to be a single
column. So you can have an
exprn_mapper<float>, but you can't have an
I've explained the “
but why “
That's because another job of an
is to convert computed results from a column format to a C++ type (although
never the reverse). E.g. if quince were to execute the query
it would rely on
to convert the results.
exprn_mappers are built
-- by applying several devices, some of which we have already seen. The
code above uses quince's overloads of
which correspond to the obvious SQL operators. Earlier we used
function, which corresponds to SQL's
UPPER() function, and we used
within a scalar subquery (a somewhat advanced topic that I take up later).
We also defined a C++ function of our own,
which we then called (just like
upper() etc.) in the context of building larger
exprn_mappers. That wasn't
a quince feature per se; it was just a C++ function
call; but in its context it nicely suited the conceit of writing server-side
expressions in C++ syntax. It was as though the DBMS had acquired a
function, on par with