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

Just a thought, because the spec does not limit the key size, does not mean
the implementation has to index on huge keys. For example you may choose to
index only the first 1000 characters of string keys, and then link the
values of key collisions together in the storage node. This way things are
kept fast and compact for the more normal key size, and there is a sensible

As long as the implementation behaves like it admits arbitrary key sizes, it
can actually implement things how it likes.

Another example would be one index for keys less than size X, and a separate
"oversize" key index for keys of size greater than X. These could use a
different internal structure and disk layout.


On 20 November 2010 04:13, Bjoern Hoehrmann <> wrote:

> * Jonas Sicking wrote:
> >The question is in part where the limit for "ridiculous" goes. 1K keys
> >are sort of ridiculous, though I'm sure it happens.
> By "ridiculous" I mean that common systems would run out of memory. That
> is different among systems, and I would expect developers to consider it
> up to an order of magnitude, but not beyond that. Clearly, to me, a DB
> system should not fail because I want to store 100 keys á 100KB.
> >> 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.
> >
> >I don't understand what you mean here.
> I am saying that it's quite natural to want to have string keys that are
> much, much longer than someone might envision the length of string keys,
> mainly because their notion of "string keys" is different from the key
> length you might get from serializing arbitrary objects.
> --
> Björn Höhrmann · ·
> Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·

Received on Saturday, 20 November 2010 09:02:36 UTC