Re: [IndexDB] Proposal for async API changes

On Wed, Jun 9, 2010 at 3: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.
>
>
> 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?

At the very least, explicitly loading things into an honest-to-god
array can make it more obvious that you're eating memory in the form
of a big array, as opposed to just a "magically transform my blob of
data into something more convenient".

(That said, I dislike cursors and explicitly avoid them in my own
code.  In the PHP db abstraction layer I wrote for myself, every query
slurps the results into an array and just returns that - I don't give
myself any access to the cursor at all.  I probably like this better
simply because I can easily foreach through an array, while I can't do
the same with a cursor unless I write some moderately more complex
code.  I hate using while loops when foreach is beckoning to me.)

~TJ

Received on Wednesday, 9 June 2010 22:37:16 UTC