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

Something working (but with degraded performance) is better than not working
at all.  Especially when keys will often come from user data/input and thus
simple web apps will likely not handle the exceptions large keys might
generate.  Throughout the rest of IndexedDB, we've taken quite a bit of care
to make sure that we don't throw exceptions on hard to anticipate edge
cases, I don't think this is terribly different.

Storing a prefix and then doing lookups into the actual value seems like a
good way for implementations to handle it, but it's certainly not the only
way.  Yes, this will turn into linear performance in the worst case, but in
practice I think you'll find that before the linear performance kills you,
various other issues with using IndexedDB like this will kill you.  :-)

I'm fine with us adding non-normative text reminding people that large keys
will be slow and having a recommended minimum key size that implementations
should try and make sure hits a reasonably fast path.  But I think we should
make sure that implementations don't break with big keys.

J

On Sat, Nov 20, 2010 at 10:49 AM, Jonas Sicking <jonas@sicking.cc> wrote:

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