[whatwg] Comments on updated SQL API

[Maciej Stachowiak]

On Oct 17, 2007, at 12:33 AM, Brady Eidson wrote:

> An admirable goal - one that I agree with.  Which is why I think the  
> wisdom of the implicit transaction is dubious.  Developers that will  
> be using SQL will know they can say "BEGIN TRANSACTION;" and  
> "COMMIT;" or "ROLLBACK;" so the utility of having transactions will  
> not be lost.  Ditching it would help thin the API further, clearing  
> up this confusion and complexity.


Downsides to this approach:

- You could only have one transaction in flight at once, so you'd have  
to do scheduling in the app code if a transaction-starting UI  
operation happens while you already have a transaction in progress.  
Otherwise multiple transactions would get scrambled. (Or else the API  
layer could parse your statements and understand when you have opened  
a transaction to still implicitly assign statements in your callbacks  
to the transaction, but I am not sure this is a simplification overall.)

- An author mistake (like doing something that causes an exception in  
the callback) means a stuck lock, quite possibly ruining the whole  
session.

With a synchronous API and threads this wouldn't be a problem, because  
we could provide a wrapper function that would bracket your code with  
BEGIN TRANSACTION and the appropriate of ROLLBACK or COMMIT depending  
on whether you throw an exception, and each thread would be using a  
different database connection. But with the async API, you create much  
more opportunity for author error.

I think the current model is not really as hard to understand as it  
might seem from the spec, which has to be very precise for the sake of  
implementations and does not make for a good tutorial.

We should test whether the performance benefits of not using  
transactions are significant. If we need to provide both I might  
suggest startTransaction or startSqlTransaction that would act like  
the current executeSql, and executeSql which acts as currently if  
there is a current transaction, but doesn't start one if none is open.

Regards,
Maciej