Thank you Jim :)
I will start on this now.
/Lars-Erik
On Sun, 2008-12-07 at 13:44 -0500, Jim Starkey wrote:
> 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.
>
