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 [1][2] 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 query:
select(streets.name) .from(streets) .where( intersects(streets.geometry, some_polygon) )
or
select(streets.name) .from(streets) .where( streets.geometry.within(from_wkt("POLYGON((0 0,10 0,10 10,0 10,0 0))")) ) <snip>
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 included? 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, sqlpp::tag::expression>; 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. Exactly :-)
<snip>
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? Ah, ok! 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.
<snip>
Hope this helps. Are you asking for a specific project? Or just out of curiosity? 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.
OK, cool! 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, http://docs.oracle.com/cd/B19306_01/server.102/b14200/queries003.htm 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 I may. Cheers, Roland