[whatwg] Gigantoredesignorrific changes to the Database API

[Brady Eidson]

On Oct 25, 2007, at 7:26 PM, Dimitri Glazkov wrote:

> I like the operation structure, imposed by the new spec: (database
> (transaction (statement (handler)))), and error callbacks are nice. A
> couple of things stood out:
>
> 1) The transactions are now required and this seems like an
> unreasonable performance hit. What if the API would assume transaction
> mode, but would allow authors to explicitly state that the operation
> is not a transaction:
>
> db.operation(function(op) {
>   // implicitly a transaction
> });
> db.operation(function(op) {
>   // explicitly not a transaction, just a set of statements in one  
> context.
> }, null, false /* states that this is not a transaction */);
>
> .. or something along these lines.

I think we've established that with at least a few popular sql  
implementations - if you use things correctly - wrapping single  
statements in transactions does not affect performance in a critical  
manner.

That consideration aside, having the "Transaction" as the basic work  
unit in the API keeps things very clean and solves a lot of problems.   
It implicitly helps with simultaneous access to the same database from  
different browsing contexts (or even different processes) and it  
simplifies both the API and implementations.

Also, there's nothing stopping web developers from running a single  
statement in a transaction.

With the way Transactions are worked into the new API, I'm convinced  
we don't need to add more API just to let a developer run a  
transaction-less statement.

> 2) Fully asynchronous is scary. Are we sure this is going to be
> well-digested? I can just see people doing this:
>
> db.operation(function(tx) {
>   var count;
>   tx.executeSql("SELECT COUNT(*) AS C FROM BLAH;", function(r) {
>       count = r.item(0).c;
>   });
>   if (count > 0) {
>        // do happy things.
>   }
> });

I am very pleased that this entire API is designed around the fact  
that "synchronous I/O on the main thread is bad," and would argue  
against any attempt to introduce synchronous I/O without an extremely  
compelling argument.
I don't think "unskilled/uninformed developers might use the API  
incorrectly" is compelling enough to change the design and give them  
the power to do I/O on the main thread.
There are various JS libraries - some very popular - that make  
"challenging" APIs easier to use, but I really don't think this one is  
all that challenging!

> 3) I think I misunderstand step 11, help me out. If the commit has
> failed once, why try to re-commit, even if the error callback
> instructs you to?

Trying to commit a failed transaction twice won't result in any  
negative side effects, but it's also probably not necessary.

If a way could be found to rewrite the Transaction Steps to work  
around this, but still keep the steps clear and unambiguous, I would  
be okay with that.

~Brady