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