[whatwg] executeSql API is synchronous

[Aaron Boodman]

On Sep 23, 2007 8:28 AM, David <leunen.d at gmail.com> wrote:
> Can someone point me out when the SQLCallback is called exactly ?
> Is it when the ResultSet is full or, as soon as the first row is available ?
>
> What if I want to handle the RS by blocks of 100 rows ?
> Wouldn't it be better to let the developer control the threading behaviour
> of his I/O accesses ?

The design of the callback was to be called once for the entire query.
The argument to the callback was to be a cursor that you can use to
iterate the rows.

But your question about whether it gets called when the first row is
available or when they are all available made me remember why on the
Gears team we wanted to have something that returns all the rows for a
query as an array.

The problem is that the cursor that is opened when you start a query
needs to be explicitly closed. It is really easy to forget to do this,
and we wanted to design an API that would make it hard to mess this
up.

I think the best way to do this is to have an API that will iterate
the resultset for you and copy all the values into an array of
objects:

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).

The downside is that for some difficult types of queries that involve
application-level filtering, this can be wasteful. That is why you
might want a lower-level iteration API as well. One way that you could
get this while at the same time avoiding blocking the UI thread while
stepping through the results is to have a callback for every row like
David suggested.

- a