List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:October 17 2008 7:51pm
Subject:Re: MYSQL_TYPE_YEAR
View as plain text  
Vladislav Vaintroub wrote:
>   
>> -----Original Message-----
>> From: falcon-return-43-wlad=sun.com@stripped [mailto:falcon-
>> return-43-wlad=sun.com@stripped] On Behalf Of Jim Starkey
>> Sent: Friday, October 17, 2008 6:35 PM
>> To: falcon@stripped
>> Subject: MYSQL_TYPE_YEAR
>>
>> Here is the server code that handles the type:
>>
>>     longlong Field_year::val_int(void)
>>     {
>>       ASSERT_COLUMN_MARKED_FOR_READ;
>>       int tmp= (int) ptr[0];
>>       if (field_length != 4)
>>         tmp%=100;                    // Return last 2 char
>>       else if (tmp)
>>         tmp+=1900;
>>       return (longlong) tmp;
>>     }
>>
>> This is easily the stupidest type I've had the displeasure to run into.
>> One type, two inconsistent sets of semantics.  Given the actual year of
>> 2008, one will return 08, the other 2008.  In either case, hower, an
>> indexed search will give 2008 as a key.
>>     
>
> It can be 108 with field_length=4 (default)
>
>   
>> What a mess!
>>
>> I suggest that StorageInterface::encodeRecord and ::decodeRecord do
>> their own handling using the field->ptr and do a translation into/from
>> normal years.
>>     
>
>
> It does not seem to help the search. If we decode 108 to 2008 , the search
> will still look for 108.
> Yet, if we do not convert and do not use val_int, but just handle
> field->ptr[0] as Falcon int in all cases, 
> then nothing has to be done further.
>
>   

You're right.  My test query suffered from fumble-fingers.

Both flavors of 2008 for YEAR do an index search of 108.

The YEAR(2) stores 2008 as 108 and return 8 from field->val_int().

The YEAR(4) also stores 2008 as 108 but returns 2008 from field->val_int();

Interesting the key value matches the physical but not logical values.

The key format doesn't contain enough information to know what's going 
on, so the path of least resistance for StorageInterface::encodeRecord 
and ::decodeRecord to bypass field->val_int() and just use the physical 
value pointed at by field->ptr. 

-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376

Thread
MYSQL_TYPE_YEARJim Starkey17 Oct
  • RE: MYSQL_TYPE_YEARVladislav Vaintroub17 Oct
    • Re: MYSQL_TYPE_YEARJim Starkey17 Oct