Re: [boost] sqlpp11, 3rd iteration

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 [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