Re: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?

* Pablo Castro wrote:
>>> Just looking at this list, I guess I'm leaning towards _not_ limiting the
>>> maximum key size and instead pushing it onto implementations to do the hard
>>> work here.  If so, we should probably have some normative text about how bigger
>>> keys will probably not be handled very efficiently.
>
>I was trying to make up my mind on this, and I'm not sure this is a good idea.
>What would be the options for an implementation? Hashing keys into smaller values
>is pretty painful because of sorting requirements (we'd have to index the data
>twice, once for the key prefix that fits within limits, and a second one for a
>hash plus some sort of discriminator for collisions). Just storing a prefix as
>part of the key under the covers obviously won't fly...am I missing some other option?
>
>Clearly consistency in these things is important to people don't get caught off
>guard. I wonder if we just pick a "reasonable" limit, say 1 K characters (yeah,
>trying to do something weird to avoid details of how stuff is actually stored),
>and run with it. I looked around at a few databases (from a single vendor :)),
>and they seem to all be well over this but not by orders of magnitude (2KB to
>8KB seems to be the range of upper limits for this in practice).

No limit would be reasonable, the general, and reasonable, assumption is
that if it works for X it will work for Y, unless Y is ridiculous. There
is also little point in saying for some values of Y performance will be
poor: implementations will cater for what is common, which is usually
not a constant, and when you do unusual things, you already know that it
is not entirely reasonable to expect the "usual" performance.

Note that, since JavaScript does not offer key-value dictionaries for
complex keys, and now that JSON.stringify is widely implemented, it's
quite common for people to emulate proper dictionaries by using that to
work around this particular JavaScript limitation. Which would likely
extend to more persistent forms of storage.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Saturday, 20 November 2010 03:03:30 UTC