Hi Jonas,
On Wed, Jun 9, 2010 at 11:27 PM, Jonas Sicking <jo...@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
am afraid that, by allowing getAll(), we are designing an API may or
may not work depending on how large the underlying data set is and
what platform the code is running on (e.g. a mobile with a few MB of
RAM available or a desktop with a few GB free). To me, that is not
ideal.
>
> 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(). Like you said, perhaps it's best to leave this method out
for now and see what kind of feedback we get from API users. If there
is demand, we can add it at that point?
Thanks,
Andrei
