Subject: Re: [boost] sqlpp11, 3rd iteration
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-21 17:16:15
On 2014-08-21 22:50, Adam Wulkiewicz wrote:
> Roland Bock wrote:
>> On 2014-08-21 18:45, Adam Wulkiewicz wrote:
>>> Which brings me to a question about the SQL extensions. In order to
>>> support such extensions, e.g. SQL/MM or SQL/SFA  which specifies
>>> a storage, access model, operations, etc. for handling of
>>> geometrical/geographical data, a user would be forced to extend your
>>> library with additional functions/methods/structures to e.g. perform a
>>> .where( intersects(streets.geometry, some_polygon) )
>>> .where( streets.geometry.within(from_wkt("POLYGON((0 0,10 0,10
>>> 10,0 10,0 0))")) )
>>> Would the user be forced to implement it in the library directly and
>>> e.g. always include it with the rest of the library? Or would it be
>>> possible to implement it as a separate addon that could be optionally
>> The latter. sqlpp11 uses value type and tags. If your class says it is
>> an sqlpp expression with a boolean value type, then it welcome wherever
>> a boolean sql expression is required.
>> struct sample
>> using _traits = sqlpp::make_traits<sqlpp::boolean,
>> using _recursive_traits = sqlpp::make_recursive_traits<>;
>> This is a boolean expression as far as sqlpp1 is concerned.
> Great, so the extension like this could be included if needed or even
> be a standalone library.
>>> If such errors was reported at compile-time then AFAIU specific
>>> version of the library (or just a lowest level connector?) would be
>>> forced to work with specific version of a server?
>> I am not sure I fully understand your question.
> Let me clarify. Let's say that I supported this ST_CoveredBy()
> function for both PostGIS and MySQL. Let's say that in version 5.9
> MySQL will support this function. So the library should work with some
> future release. But I'm using sqlpp with MySQL 5.7. What will be the
> result of performing this "unsupported" query? An exception? AFAIU
> ideally it should be a compile-time error?
I think I would make the connector a template, giving it a major and
minor version number. You could then use that version information in a
static assert in the serializer for that function.
That's my first idea.
Alternatively, depending on the amount of changes, it might even make
sense to write a new connector. The connector libraries are rather small.
>> Hope this helps. Are you asking for a specific project? Or just out of
> I'm curious. I'm a contributor at Boost.Geometry and this is just a
> problem from my domain.
> I'm wondering what would be needed to use sqlpp in a
> GIS/Geometry-related application. E.g. to load some geometrical
> objects from some database into objects of types adapted to
> Boost.Geometry concepts (polygon, linestring, etc.), do something with
> them and maybe write the results back or display them, etc. Something
> like that.
Let me know if it should become more concrete :-)
>> FYI: There is one more way to extend sqlpp11 queries: You can add
>> additional clauses or change the interface of clauses. For instance,
>> uses a CONNECT clause in SELECT.
>> That also isn't very hard, but I would not call it really simple
>> either :-)
> Thanks for the answers and tips!
Thanks for the questions. I'll use some of that in my talk at CppCon, if
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk