- From: Scott Hess <shess@google.com>
- Date: Wed, 31 Oct 2007 17:32:25 -0700
On Oct 31, 2007 5:21 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 31 Oct 2007, Timothy Hatcher wrote: > > How is that wrong? If the first executeSql fails the error callback (if > > any) will fire, not the normal callback. > > > > db.executeSql('CREATE TABLE ...', [], function(...) { > > db.executeSql('INSERT INTO ...', []); > > }); > > > > If the CREATE TABLE fails, the insert will never happen. If the INSERT > > fails, you don't really want the table to be rolled out. If you did, > > then you want a transaction. There are clearly times where you don't > > always want a transaction, but want to chain statements. > > What if another page dropped the table between the CREATE and the INSERT? What if you went to insert into a table that someone else had dropped in any case? I think Timothy's point is that for the simple case where you really _do_ intend to execute an ordered sequence of SQL statements which aren't in a transaction, the new API is a bit more convoluted. I think his point is sound, but I'm not certain how important that use-case is. Realistically, you're usually either executing a singleton statement, or you're executing a set of logically connected statements which want to be in a single transaction. I think that there might be some value to having better support for a singleton statement, though. Right now, your result-set handling is inside the implicit transaction. With a singleton executeSql() API off of Database, your resultset handling could be pushed out of the transaction, which would be good. -scott
Received on Wednesday, 31 October 2007 17:32:25 UTC