Re: [IndexDB] Proposal for async API changes

On Thu, Jun 10, 2010 at 11:17 AM, Andrei Popescu <andreip@google.com> wrote:
> On Thu, Jun 10, 2010 at 5:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, Jun 10, 2010 at 4:46 AM, Andrei Popescu <andreip@google.com> wrote:
>>> Hi Jonas,
>>>
>>> On Wed, Jun 9, 2010 at 11:27 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>
>>>> I'm well aware of this. My argument is that I think we'll see people
>>>> write code like this:
>>>>
>>>> results = [];
>>>> db.objectStore("foo").openCursor(range).onsuccess = function(e) {
>>>>  var cursor = e.result;
>>>>  if (!cursor) {
>>>>    weAreDone(results);
>>>>  }
>>>>  results.push(cursor.value);
>>>>  cursor.continue();
>>>> }
>>>>
>>>> While the indexedDB implementation doesn't hold much data in memory at
>>>> a time, the webpage will hold just as much as if we had had a getAll
>>>> function. Thus we havn't actually improved anything, only forced the
>>>> author to write more code.
>>>>
>>>
>>> True, but the difference here is that the author's code is the one
>>> that may cause an OOM situation, not the indexedDB implementation.
>>
>> I don't see that the two are different. The user likely sees the same
>> behavior and the action on the part of the website author is the same,
>> i.e. to load the data in chunks rather than all at once.
>>
>> Why does it make a different on which side of the API the out-of-memory happens?
>>
>
> Yep, you are right in saying that the two situations are identical
> from the point of view of the user or from the point of view of the
> action that the website author takes.
>
> I just thought that in one case, the website author wrote code to
> explicitly load the entire store into the memory, so when an OOM
> happens, the culprit may be easy to spot. In the other case, the
> website author may not have realized how getAll() is implemented and
> may not know immediately what is going on. On the other hand, getAll()
> asynchronously returns an Array containing all the requested values so
> it should be just as obvious that it may cause an OOM. So ok, this
> isn't such a big concern after all..

That was my reasoning yes. In both cases the author is requesting an
array filled with a hunk of data. It's just different syntaxes.

>>>> Put it another way: The raised concern is that people won't think
>>>> about the fact that getAll can load a lot of data into memory. And the
>>>> proposed solution is to remove the getAll function and tell people to
>>>> use openCursor. However if they weren't thinking about that a lot of
>>>> data will be in memory at one time, then why wouldn't they write code
>>>> like the above? Which results as just as much data being in memory?
>>>>
>>>
>>> If they write code like the above and they run out of memory, I think
>>> there's a chance they can trace the problem back to their own code and
>>> attempt to fix it. On the other hand, if they trace the problem to the
>>> indexedDB implementation, then their only choice is to avoid using
>>> getAll().
>>
>> Yes, their only choice is to rewrite the code to read data in chunks.
>> However you could do that both using getAll (using limits and making
>> several calls to getAll) and using cursors. So again, I don't really
>> see a difference.
>>
>
> Well, I don't feel very strongly about it but I personally would lean
> towards keeping the API simple and, where possible, avoid having
> multiple ways of doing the same thing until we're sure there's demand
> for them...

I agree, we have largely stayed away from syntactic sugar. However
there are a few cases, like get(), getAll(), openObjectCursor() and a
few more, where it seems like an operation is so common, and the API
so simple, that it's worth adding.

But if others really want to, i'm fine with leaving getAll() out of
the spec for now and we'll attempt to gather author feedback.

/ Jonas

Received on Thursday, 10 June 2010 18:40:05 UTC