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

[whatwg] Comments on updated SQL API

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 25 Sep 2007 03:29:43 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0709250310280.21662@hixie.dreamhostps.com>
On Sat, 22 Sep 2007, Aaron Boodman wrote:
> 
> 4.12.3, step 3:
> 
> I don't think you should implicitly join active transactions unless
> you're inside a callback from a previous executeSql call.

That's what the spec requires. I've tried to make it a bit clearer.


> Otherwise all code that wants to call executeSql needs to know about all 
> other code using it and know to wait if it wants isolation. In the case 
> where you're a top-level call to executeSql, you should start a new 
> transaction.

That's what the spec does.


> Some thought needs to be given to the type of transaction that should be 
> started implicitly. Most database vendors support several. Here is the 
> list of SQLite's:
> 
> http://www.sqlite.org/lang_transaction.html
> 
> I think the "immediate" type is the best all-around choice.

In the case of SQLite, with the API as specced, there would be no 
different between DEFERRED (the default in recent versions) and IMMEDIATE, 
as you can only start a transaction by doing a statement.

But yeah. I think we'll have to define the SQL subset in more detail at 
some point, and at that point, more detail will have to be defined in 
terms of what transaction support we should have.


> 4.12.3, step 5: I think you need to fail with a specific error so that 
> the caller knows this is the problem and can do the right thing

There is an error code for this condition (version mismatch); see the 
table lower down.


> I don't think closeTransaction() is necessary. For one thing, SQL 
> already has "COMMIT" and "ROLLBACK". Secondly, if the developer wants 
> each statement to be it's own transaction, he can make separate 
> top-level calls.

The reason for closeTransaction() is as follows:

   var database = window.openDatabase('test', '1.0');
   database.executeSql('INSERT INTO foo (x) VALUES (1)', function (result) {
     if (result.errorCode) {
       // it broke, transaction has rolled back
       // if we just call executeSql() here, it'll fail
       database.closeTransaction();
       ... // ok now we can call executeSql() and it'll work
       return;
     }
     ... // do whatever the rest of the transaction will be
   });

We require this because we want this to fail:

   var database = window.openDatabase('test', '1.0');
   database.executeSql('INSERT INTO foo (x) VALUES (1)', function (result) {
     // no error checking
     // the following call will raise an exception if the previous call
     // failed, so that we don't ignore errors recklessly
     database.executeSql('INSERT INTO foo (x) VALUES (2)', function (result) {
       // ...
     });
   });

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

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