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

On Fri, Nov 19, 2010 at 8:13 PM, Bjoern Hoehrmann <derhoermi@gmx.net> 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 at issue here isn't the total size of keys, but the key size
of an individual entry. I'm not sure that I'd expect a 100KB key size
to work.

>>> 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.

Still not fully sure I follow you. The only issue here is when using
plain strings as keys, objects are not allowed to be used as keys. Or
are you saying that people will use the return value from
JSON.stringify as key?

/ Jonas

Received on Saturday, 20 November 2010 10:50:19 UTC