Serg,
On 16.10.2007, at 18:21, Sergei Golubchik wrote:
> Hi!
>
> One question, see below.
>
> On Oct 10, kgeorge@stripped wrote:
>> ChangeSet@stripped, 2007-10-10 16:26:02+03:00, gkodinov@stripped
>> +14 -0
>> Bug #30825: Problems when putting a non-spatial index on a GIS
>> column
>> Fixed the usage of spatial data (and Point in specific) with
>> non-spatial indexes.
>> Several problems :
>> - The length of the Point class was not updated to include the
>> spatial reference system identifier. Fixed by increasing
>> with 4
>> bytes.
>> - The storage length of the spatial columns was not
>> accounting for
>> the length that is prepended to it. Fixed by treating the
>> spatial data columns as blobs (and thus increasing the storage
>> length)
>> - When creating the key image for comparison in index read wrong
>> key image was created (the one needed for and r-tree search,
>> not the one for b-tree/other search). Fixed by treating the
>> spatial data columns as blobs (and creating the correct
>> kind of
>> image based on the index type).
>>
>> diff -Nrup a/sql/sql_table.cc b/sql/sql_table.cc
>> --- a/sql/sql_table.cc 2007-08-05 06:53:13 +03:00
>> +++ b/sql/sql_table.cc 2007-10-10 16:26:00 +03:00
>> @@ -1287,7 +1287,7 @@ static int mysql_prepare_table(THD *thd,
>> }
>> if (f_is_geom(sql_field->pack_flag) && sql_field-
>> >geom_type ==
>> Field::GEOM_POINT)
>> - column->length= 21;
>> + column->length= 25;
>
> how did it work before ? wouldn't wrong length result in truncated
> POINT
> values on disk ?
It wasn't working before (non-spatial indexed search over spatial data).
Yes : this was exactly the case : the data were truncated in
_mi_make_key().
Best Regards,
Joro
--
Georgi Kodinov, Senior Software Engineer
MySQL AB, Plovdiv, Bulgaria, www.mysql.com
Office: +359 32 634 397 Mobile: +359 887 700 566 Skype: georgekodinov
Are you MySQL certified? www.mysql.com/certification
