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

Any more thoughts on this?

On Mon, Nov 22, 2010 at 12:05 PM, Jeremy Orlow <jorlow@chromium.org> wrote:

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