- From: Scott Hess <shess@google.com>
- Date: Fri, 5 Oct 2007 16:36:44 -0700
On 9/24/07, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 23 Sep 2007, David wrote: > > What if I want to handle the RS by blocks of 100 rows ? > > Why wouldn't you just want to do everything? For the case of a database with a 5M size limit, never. If app developers, users, and browsers all agree that they want to run some app with a substantial local database footprint, one could imagine an accidental "select * from blog_postings_Ive_read" taking 2GB of memory encoded as UTF-16. Obviously this would be a mistake, which a developer would want to work around by using LIMIT or something of the sort in the query, but you're possibly still stuck killing your browser to get out from underwater. If the callback received a result object which could be iterated over, and had isValidRow() and isRowAvailable() both, then it could buffer things AND break things into blocks, but that's probably annoying to spec and code to. It may be worthwhile to have explicit support for an error on the order of "result set too large", without defining what "too large" might mean. That could be a per-user-agent preference (or constant), and the error mainly exists so that you can tell that you have a problem and provide a lightweight code path if you want to support that user-agent. Regardless, if gives the implementation the latitude to say "This far, and no farther". -scott
Received on Friday, 5 October 2007 16:36:44 UTC