Re: [IndexDB] Proposal for async API changes

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

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

Thanks,
Andrei

Received on Thursday, 10 June 2010 18:18:09 UTC