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)
>> int tmp= (int) ptr;
>> if (field_length != 4)
>> tmp%=100; // Return last 2 char
>> else if (tmp)
>> 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 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.
President, NimbusDB, Inc.