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;
> INSERT INTO t1 VALUES ('8');
> 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
StorageDatabase::getSegmentValue.
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.
