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

[whatwg] executeSql API is synchronous

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 25 Sep 2007 01:14:49 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0709250111520.21662@hixie.dreamhostps.com>
On Wed, 8 Aug 2007, Maciej Stachowiak wrote:
> 
> The executeSql() API returns a result synchronously. In general, SQL 
> databases may be slow to access since they need to be read from disk, 
> and if the database is not open already there's unlikely to be a ready 
> cache. This may make it hard to use the executeSql() API without 
> blocking the UI. All other HTML DOM operations that may require I/O to 
> complete are asynchronous, with the exception of synchronous 
> XMLHttpRequest which (a) causes UI lockup problems in practice and (b) 
> at least has an async variant.

I've changed the API to be async.


On Wed, 8 Aug 2007, Aaron Boodman wrote:
>
> FWIW, We (the gears team) considered adding an async version of our sql 
> execute() method, but decided against it in favor of improving the 
> workerpool.

I don't think we want to require all database access to go through a 
worker pool. But I agree we will want synchronous APIs in a worker pool 
scenario.


On Thu, 20 Sep 2007, Timothy Hatcher wrote:
>
> The pain of asynchronous access can be alleviated or even solved with an 
> API for transactions, or a group of SQL queries that need be executed in 
> order. Commonly, if a transaction fails in the middle, the database is 
> rolled-back to the state before the transaction started.
> 
> There can then be a callback when the transaction finished or fails, 
> with details on what query failed.

I've also added support for implicit transactions.


On Thu, 20 Sep 2007, Aaron Boodman wrote:
>
> It sounds like what you're talking about is something like:
> 
> var tx = new Transaction();
> tx.addStatement("insert into accounts values (?, ?)", ["foo", "bar"]);
> tx.addStatement("update persons set name = ?, age = ?", ["bob", 42]);
> tx.executeAsync(callback, errback);
> 
> This only works so long as you can construct all the sql calls ahead of 
> time. If any calls depend on the results of previous ones, you need 
> something like a worker.
> 
> But I agree that the api needs support for transactions, I wanted to 
> start another thread about that.

I'll respond on that thread.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 24 September 2007 18:14:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:57 UTC