W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [IndexedDB] onsuccess isn’t the best for writes

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 20 Mar 2012 18:09:21 -0500
Message-ID: <CABirCh-wuKRGANJzvmxp-HFArm4-XwFdRthOad35VZa74cX8yA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Yonathan <yonathan@gmail.com>, public-webapps@w3.org
"Create a transaction" step 4 says "create a transaction", whcih is
recursive.

The bolded phrase "create a transaction" is never used.  It looks like this
is out of sync: the phrase actually used is "steps for creating a
transaction".  They should match exactly, to allow searching.

On Mon, Mar 19, 2012 at 11:49 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> > It also seems inconsistent: the transaction is aborted if code fails
> inside
>
> onsuccess, but not if it fails almost anywhere else, which seems much more
> > likely anyway.  I don't think anything else on the platform has special
> > error handling like this; I'd recommend just removing it.
>
> What do you mean by "anywhere else"? Most transaction handling will be
> inside event handlers.
>

But inside *other* events, like onclick, not from onsuccess.  From the
beginning of this thread, it sounds like listening for onsuccess may even
be uncommon, and probably more often used for non-database things, like
updating a progress bar (where aborting the transaction doesn't make sense).

In the common case, you have to handle errors yourself:

e.onclick = function() {
  trans = db.transaction(...);
  try {
    trans.objectStore(...).put(x());
    trans.objectStore(...).put(y());
  } catch(e) {
    trans.abort();
    throw e;
  }
}

I don't think it helps to do this magically in an uncommon case, when
everyone needs to be in the habit of doing it manually in the common case
anyway.  It just seems confusing and arbitrary.

(Aborting due to exceptions from synchronous callbacks is fine, though,
since it's consistent: *all* requests on the transaction happen inside it.)

-- 
Glenn Maynard
Received on Tuesday, 20 March 2012 23:09:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT