[whatwg] executeSql API is synchronous

[Aaron Boodman]

On Sep 24, 2007 9:22 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sun, 23 Sep 2007, Aaron Boodman wrote:
> >
> > db.executeSQL("select * from person where id = ?", [42], function(result) {
> >   // result is an array of objects
> > });
> >
> > Another issue that this design addresses is that it avoid blocking the
> > UI for IO while iterating the results (all the results can be iterated
> > on a different thread).
>
> This is basically what the spec does now. There is some debate about
> whether the results should actually be an Array or not though, to allow
> for a lazy caching implementation if desired.

I like the current specification of ResultSet:
http://www.whatwg.org/specs/web-apps/current-work/#sqlresultset

If you are not planning on changing it, you can stop reading now :)
Otherwise, read on.

When you read from SQLite (and probably other databases) you acquire a
read lock ("shared"). This lock needs to be released explicitly
because no writes can occur while it is open.

There are basically three options for determining the lifetime of this lock:

* Push: The implementation reads all the results immediately, releases
the lock, and closes. This is what I'm advocating.
* Pull: caller requests rows as needed and explicitly closes the lock
when it is done. This is what Gears does today.
* A race! The implementation returns immediately and starts populating
results in the background. When it's done, it releases the lock. If
the caller requests a row that isn't available yet, the request blocks
until it is.

I think that pure pull is a bad idea because callers always forget to
close the resultset. You cannot rely on GC because it is
non-deterministic.

The race doesn't seem that great either because if the caller does this:

alert(resultset.rows[resultset.rows.length])

We block the UI and lose all the benefit of having the API be
asynchronous in the first place.

Therefore push seems simplest and best IMO. It's true that it is
inefficient in certain special cases, but we could add a different
push API (with a callback on each row) to work around that problem if
it really is a problem.

- a