List:Falcon Storage Engine« Previous MessageNext Message »
From:Vladislav Vaintroub Date:October 17 2008 5:00pm
Subject:RE: MYSQL_TYPE_YEAR
View as plain text  

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


> --
> Jim Starkey
> President, NimbusDB, Inc.
> 978 526-1376
> 
> 
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe:    http://lists.mysql.com/falcon?unsub=1


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