maria-developers team mailing list archive

[Mateusz Loskot <mateusz@xxxxxxxxxx>]

On 24 September 2013 02:49, Roberto Spadim <roberto@xxxxxxxxxxxxx> wrote:
> 2013/9/23 Mateusz Loskot <mateusz@xxxxxxxxxx>
>>
>> I'm going to ask question about how the current Spatial Extensions are
>> implemented.
>> I have spent some time reading the source code in the current trunk
>> (spatial.h|cc, gcal*.h|cc, related Field and Item definitions, etc.),
>> so I have a rough understanding of the overall structure, how the
>> geometry data types are implemented and exposed to SQL, how the
>> spatial functions are defined and registered. I did not looked into
>> details of implementation of geospatial algorithms, but that's too low
>> level for the question I'm going to ask.
>>
>> Initially, I was going to ask very detailed question, listing all the
>> relevant code definitions and asking separately about each of them,
>> but that's not necessary at this stage, I think.
>>
>> Instead, I'm going to simplify and ask about the bigger picture, more
>> about MariaDB extensions API:
>>
>> 1. Is it possible to implement MariaDB extensions like Spatial (custom
>> type + set of functions) without such a tight coupling with the
>> internal implementation of the type system (without messing Field
>> class with geometry types directly, etc.)?
>
>
> i think this is something interesting, check this idea:
> https://mariadb.atlassian.net/browse/MDEV-4912
> well this MDEV is too far from today (it's an idea to mariadb 10.1 we are at
> 10.0.5 today...)
> forget this MDEV... you can extend mariadb with your hands too :)

This something interesting indeed.

>> 2. Is it possible to implement Spatial using User-Defined Functions
>> (UDF) defined in shared binary?
>
> yes, the field type probably will be a WKB value and a STRING/BLOB (char)
> type, must check i never used a UDF for spatial data

That answers my question. So, it also means serialising/deserialising
is unavoidable.


>> 3. What is the reason behind using Well-Known-Binary (WKB) stream of
>> bytes to transport geometry values into/from functions? Is it due to
>> limitations of MariaDB type system where String is  the only universal
>> carrier for complex data? This concern is related to necessity of
>> encoding/decoding WKB when chaining spatial function calls, and
>> possibilities to avoid it.
>
>
> internally (at memory / disk) you have a string (for spatial type it's a WKB
> format string), and at run/compile/design time you have a class (many
> functions) that handle this type (string in this case)
> [...]

I do understand those principles.
My question however along this lines: is there a type system in MariaDB/MySQL
which allows to avoid going through WKB stream as the only
input/output data into/from functions?

IOW, instead of slinging WKB around the spatial functions, optimally if it was
possible to pass ready to use structured objects.

See this PostGIS wiki page about LWGEOM which is a working structure
for all spatial functions:

http://trac.osgeo.org/postgis/wiki/DevWikiPostGISCoding

So, instead of (pseudo-code):

foo(String s1, String s2) {
   g1 = decode_geometry_from_wkb(s1)
   g2 = decode_geometry_from_wkb(s2);
   g3 = call_fancy_algorithm(g1, g2);
   return encode_geometry_to_wkb(g3)
}

optimal protocol is this:

foo(MyGeometry g1, MyGeometry g2) {
   g3 = call_fancy_algorithm(g1, g2);
   return g3;
}

Is his feasible in MariaDB extensions?

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
"Participation in this whole process is a form of torture" ~~ Szalony