Re: IndexedDB: MultiEntry index limited to 50 indexed values? Ouch.

You are correct:

A case of BROKEN debugging tool (Chrome Web Console in Chrome 35) and a
typo that produced no error (I had e.target.cursor instead of
e.target.result)

If the debugger is broken (I realize it's been fixed now) it makes it hard
to tell weather the bug is in my code or in the implementation.

Given our prior conversation on this list resulted in some useful feedback,
according to you, I figured that you wanted to continue getting feedback on
this list. I guess the distinction to make is between reports of potential
bugs (which should go to chromium-html5 unless they are cross browser in
which case I'd post them here, right?)  and API design issues (spec issues)
which is what my other post from a couple weeks ago was about. If it's the
latter then I'll post here, right? If the former I'll post to
chromium-html5. Since I only use Chrome in my current work, I'll probably
never bother verifying any bugs I find on other browsers, so I'll direct
them to chromium-html5.

Anything else?

Thanks for coding the test, and will post more DEBUGGER BUGS on
chromium-html5 that impact debug-ability of IDB apps. There are at least a
couple more.




On Thu, Jun 5, 2014 at 2:53 PM, Joshua Bell <jsbell@google.com> wrote:

> The spec has no such limitation, implicit or explicit. I put this together:
>
> http://pastebin.com/0GLPxekE
>
> In Chrome 35, at least, I had no problems indexing 100,000 tags. (It's a
> bit slow, though, so the pastebin code has only 10,000 by default)
>
> You mention 50 items, which just happens to be how many records are shown
> on one page of Chrome's IDB inspector in dev tools. And paging in the
> inspector was recently broken (known bug, fix just landed:
> http://crbug.com/379483). Are you sure you're not just seeing that?
>
> If you're seeing this consistently across browsers, my guess is that
> there's a subtle bug in your code (assuming we've ruled out a double-secret
> limit imposed by the cabal of browser implementors...) This isn't a support
> forum, so you may want to take the issue elsewhere - the chromium-html5 is
> one such forum I lurk on.
>
> If you're not seeing this across browsers, then this is definitely not the
> right forum. As always, please try and reduce any issue to a minimal test
> case; it's helpful both to understand what assumptions you may be making
> (i.e. you mention a cursor; is that a critical part of your repro or is a
> simple count() enough?) and for implementors to track down actual bugs. If
> you do find browser bugs, please report them - crbug.com,
> bugzilla.mozilla.org, etc.
>
>
>
> On Thu, Jun 5, 2014 at 2:15 PM, marc fawzi <marc.fawzi@gmail.com> wrote:
>
>> Hi Joshua, IDB folks,
>>
>> I was about to wrap up work on a small app that uses IDB but to my
>> absolute surprise it looks that the number of indexed values in a
>> MultiEntry index is limited to 50. Maybe it's not meant to contain an
>> infinite number but 50 seems small and arbitrary. Why not 4096?
>> Performance? If so, why is it NOT mentioned in any of the IDB docs
>> published by the browser vendors?
>>
>> Following from my previous example (posted to this list), "tags" is a
>> multiEntry index defined like so:
>>
>> objectStore.createIndex("tags", "tags", {unique: false, multiEntry: true})
>>
>> When I put in say 3000 tags as follows:
>>
>> var req = objectStore.add({tags: myTagsArray, someKey: someValue, etc:
>> etc})
>>
>> Only the first 50 elements of myTagsArray show up in the Keys column
>> within the Chrome Web Console (under Resources-->IndexedDB--->tags) and
>> it's not a display issue only: The cursor (shown below) cannot find any
>> value beyond the initial 50 values in myTagsArray. This is despite the
>> cursor.value.tags containing all 100+ values.
>>
>> var range = IDBKeyRange.only(tags[0], "prev")
>>
>> var cursor = index.openCursor(range)
>>
>> Is this by design? Anyway to get around it (or do it differently) ? and
>> why is the limit of 50 on indexed values not mentioned in any of the docs?
>>
>> I bet I'm missing something... because I can't think of why someone would
>> pick the number 50.
>>
>> Thanks,
>>
>> Marc
>>
>>
>>
>>
>
>