[whatwg] SQL API complex for simple cases

[Ian Hickson]

On Wed, 31 Oct 2007, Scott Hess wrote:
> > >
> > >   db.executeSql('CREATE TABLE ...', [], function(...) {
> > >     db.executeSql('INSERT INTO ...', []);
> > >   });
> >
> > 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?

True.


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

I entirely agree. I'm just not convinced that we should have this in v1 -- 
there have been a number of arguments put forward that suggest that we 
should delay this until v2.

It's cumbersome, but the danger is that if we make it easy, that we make 
the wrong thing easier than the right thing in several important cases.


On Wed, 31 Oct 2007, Brady Eidson wrote:
> 
> I have an alternative to propose - how about reinstating 
> Database.executeSql(), and do something like this.
> 
> db.executeSql("select * from table;", [], <SQLStatementCallback>, 
> <SQLStatementErrorCallback>, <SQLTransactionErrorCallback>);
> 
> This would "fire and forget" a single, individual statement in its own 
> transaction.  It would follow transaction steps exactly as they 
> currently exist, except it would skip the SQLTransactionCallback because 
> the first sql statement to execute is already queued.

We could do that. I'm not convinced it's of enough benefit to have it in 
v1, though.


> This way you could do:
> 
> db.executeSql("SELECT * FROM Notes", [], function(tx, results) { // Start a
> new transaction with one sql statement on the queue
> 	tx.executeSql("INSERT INTO Notes...", [], ...);  // Add a new
> statement to this transaction
> 	db.executeSql("SOME OTHER SQL STATEMENT", ...); // Start a new
> transaction with its first sql statement queued up
> 	}, statementErrorCallback, txErrorCallback);

Right -- but the fear is that the subtle distinction between 
tx.executeSql() and db.executeSql() in the above code would be the source 
of many hard-to-track bugs.


> But could also do something as simple as:
> 
> db.executeSql("CREATE TABLE Notes (...)", [], NULL, NULL, NULL);
> 
> [...] But I do think this is a reasonable way to A - make it easier to 
> kick off an individual statement and B - allows the developer, in the 
> best case scenario of no failures, kick off a sql statement that runs to 
> completion with *no* callbacks.

I agree. The concern is just that we don't actually want to make this easy 
in the first version.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'