- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 10 Jun 2010 09:52:34 -0700
- To: Andrei Popescu <andreip@google.com>
- Cc: Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>, Jeremy Orlow <jorlow@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>, Webapps WG <public-webapps@w3.org>
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?
>> 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.
/ Jonas
Received on Thursday, 10 June 2010 17:00:18 UTC