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

[whatwg] SQL API and Transactions

From: Scott Hess <shess@google.com>
Date: Wed, 31 Oct 2007 14:00:32 -0700
Message-ID: <696e4b7c0710311400x55e85fd5ha71e7ecad037bb54@mail.gmail.com>
On Oct 26, 2007 3:51 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 25 Oct 2007, Brady Eidson wrote:
> > Step 9 of the transaction steps stipulates that if the transaction fails
> > to commit, the script will get an SQLTransactionErrorCallback indicating
> > this failure.  However, there is no final callback indicating *success*
> > of the commit.
<snip>
> We can add a third callback to changeVersion() and transaction(). I can't
> see any other way to solve it. What do people think? Too heavy-weight, or
> ok? I'm ok with doing it if people want it.

I agree with Brady, in many cases it will be essential to know that
the transaction has completed successfully.  On the other hand, the
system is starting to have sort of a lot of callbacks!  But if it's
going to be async, that's sort of the penalty to be paid.

One option would be to change SQLTransactionErrorCallback to
SQLTransactionCompletionCallback.  Having a separate callback is
probably better if the success-handler always looks materially
different from the failure-handler, but I think it's possible that
having a single callback with an if() inside might be less confusing
than two callbacks.

I think one could work around this within the current spec something like:

var success = true;

db.transaction(function (t) {
  t.executeSql('insert into x values (?)', [y]);
  db.transaction(function (t) {
    if (success) {
      // This should be called after the outer transaction has completed.
    }
  }
}, function (e) {
  success = false;
});

That's awful cumbersome, but if the need is seldom enough, it might be
reasonable.

-scott
Received on Wednesday, 31 October 2007 14:00:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC