List:Falcon Storage Engine« Previous MessageNext Message »
From:Vladislav Vaintroub Date:January 30 2009 1:41pm
Subject:RE: NULLs and stuff
View as plain text  
Lars, I'm pretty comfortable with the first transformation since we have
discussed this one.

i.e

After original value to key conversion with makeKey, transform

NULL => zero length key
Zero length key (e.g empty string) => 0x00
Keys in form of 0x00<something> => 0x00 0x00 <something>


This seems to retain the original sorting when keys for memcmp based
comparison and making NULL less then everything else.
I think this fixed lot of issues. But,  if we go for it, we need to issue a
big red "warning, incompatible change" in the release notes
Luckily we're still alpha and I think we can allow us to make such changes
without writing a conversion utility. 

Adding blanks was Kevin's idea I have not understood.. yet.




> -----Original Message-----
> From: Lars-Erik.Bjork@stripped [mailto:Lars-Erik.Bjork@stripped]
> Sent: Friday, January 30, 2009 2:23 PM
> To: FalconDev
> Subject: NULLs and stuff
> 
> Hi all!
> 
> This week I have been looking at http://bugs.mysql.com/bug.php?
> id=42208 (Falcon's ORDER BY .. LIMIT gives wrong/inconsistent results
> on NULL values).
> 
> The problem is that NULL values sort together with numeric zero. I
> have talked this issue over with Vlad, and have tried several
> different solutions to make it work for both single-field and multi-
> field indexes. What seems to work, is for Index::makeKey(Field *field,
> Value *value, int segment, IndexKey *indexKey) to return a zero length
> key for NULL values, and to prepend 0x00 to all keys starting with
> 0x00 (to make NULL sort before the empty (string), and to make the
> empty string, now 0x00, sort before the previous 0x00, now 0x0000,
> etc, etc)
> 
> Being in this area, I picked up http://bugs.mysql.com/bug.php?id=23692
> again, which we have discussed on a previous meeting. The idea Kevin
> proposed here (if I remember correctly) was to append 0x20 to all
> upper-bound search keys ending in >= 0x20 (Kevin, please correct me if
> my memory is corrupt). This means passing an extra argument all the
> way from StorageTable::setIndexBounds down to Index::makeKey, because
> we don't want to store the extra byte in the regular index keys.
> 
> How does the rest of you feel about these solutions? I get this hacky
> feeling:) We have to make sure there is always room for a 0x00 and a
> 0x20 in the key, meaning that the actual key can no longer be
> MAX_PHYSICAL_KEY_LENGTH long, but two less, as well as
> [prep,app]ending 0x00 and 0x20 being pretty magic.
> 
> Is this something that you are comfortable with? I don't have any
> alternative solutions:)
> 
> /Lars-Erik

Thread
NULLs and stuffLars-Erik Bjørk30 Jan
  • RE: NULLs and stuffVladislav Vaintroub30 Jan
    • Re: NULLs and stuffAnn W. Harrison30 Jan
  • Re: NULLs and stuffPhilip Stoev30 Jan
    • RE: NULLs and stuffVladislav Vaintroub30 Jan
      • RE: NULLs and stuffVladislav Vaintroub30 Jan
        • RE: NULLs and stuffHakan Kuecuekyilmaz30 Jan
          • RE: NULLs and stuffVladislav Vaintroub30 Jan
            • Re: NULLs and stuffJim Starkey1 Feb
      • Re: NULLs and stuffJim Starkey1 Feb
  • Re: NULLs and stuffKevin Lewis30 Jan
  • Re: NULLs and stuffAnn W. Harrison30 Jan
  • Re: NULLs and stuffJim Starkey1 Feb
    • Re: NULLs and stuffLars-Erik Bjørk2 Feb
      • Re: NULLs and stuffJim Starkey2 Feb
        • RE: NULLs and stuffVladislav Vaintroub2 Feb
          • Re: NULLs and stuffJim Starkey2 Feb
            • RE: NULLs and stuffVladislav Vaintroub2 Feb