List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:December 7 2008 6:44pm
Subject:Re: unsigned decimal
View as plain text  
Lars-Erik Bjørk wrote:
> Hi Jim!
> Thanks for the quick reply!
> I have already tried this one earlier, but it does not work :)
> CREATE TABLE t1 (`decimal_unsigned_key` decimal unsigned, key 
> (`decimal_unsigned_key`)) engine=falcon;
> SELECT * FROM t1 WHERE `decimal_unsigned_key` > 7;
> This does not return any rows.
Sorry, Lars, I should have looked more closely.

Here is what is actually happening:

   1. The server maps "decimal unsigned" to "decimal (10, 0) unsigned"
      (why it didn't map to 64 bit binary is a mystery)
   2. StorageInterface::genTypes maps this to Falcon "numeric (10, 0)"
   3. Falcon says, "hey, numeric (10,x) fits in a 64 bit int.  Cool."
   4. StorageInterface::encodeRecord and StorageInterface::decodeRecord
      map data between the server type MYSQL_TYPE_NEWDECIMAL and the
      internal Falcon type (no problem here).
   5. When StorageDatabase::getSegmentValue tries to translate a key
      from server format to Falcon format, it sees of key of type
      HA_KEYTYPE_BINARY with a Falcon type of 64 bit binary and does the
      obvious but wrong thing.

I recommend you get the server key decode logic out of the runtime 
(StorageDatabase::getSegmentValue) and into metadata handling 
(StorageInterface::getKeyDesc), which has the information necessary to 
figure out the actual key format.  It should map the the key into a set 
of key formats (you'll have to define the set yourself) that is saved in 
StorageSegment and used in a single switch statement in 

This, happily, will both get the right answer and be faster than the 
existing runtime test.  Unfortunately, it probably won't be sufficiently 
faster to measure, but you can still have the happy warm feeling that 
comes from fixing a bug that doesn't slow anything down.

Re: unsigned decimalJim Starkey7 Dec
  • Re: unsigned decimalLars-Erik Bjørk9 Dec