W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] executeSql API is synchronous

From: Scott Hess <shess@google.com>
Date: Fri, 5 Oct 2007 16:36:44 -0700
Message-ID: <696e4b7c0710051636i35f7f898w5a67fc3632499182@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC