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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 19 Mar 2012 12:31:44 -0700
Message-ID: <CA+c2ei9ihc1rT3m=ezEYC9oAWNgtPd-cdEsD_i0=608cEFjm2Q@mail.gmail.com>
To: Yonathan <yonathan@gmail.com>
Cc: public-webapps@w3.org
That sounds good to me. Can you file a bug in our bugzilla?

Though note that the situation is a bit more complex. If a page
expects that a write can fail with a ConstraintError then the page
might want to listen to the error event and call preventDefault() on

But yeah, I agree that listening to the "success" event or a write is
generally not very useful.

/ Jonas

On Fri, Mar 16, 2012 at 4:24 AM, Yonathan <yonathan@gmail.com> wrote:
> I’m concerned that people will listen to IDBRequest’s “success” event
> to notify when an add or put has been successfully written. For
> example, the “Using IndexedDB” article[1] recommends, “The first thing
> you'll want to do with almost all of the requests you generate is to
> add success and error handlers:” Instead, as far as I can tell,
> success listeners should only be added to read requests (get, count,
> and openCursor after each continue and advance), whereas for write
> requests you should almost always listen to the transaction’s
> “complete” event instead. The reason is that after a request succeeds,
> the transaction as a whole may yet fail due to UnknownError, as well
> as abort or an error in a later request on the same transaction if you
> don’t preventDefault(). Should the specification encourage onsuccess
> for reads and oncomplete for writes?
>  [1]: https://developer.mozilla.org/en/IndexedDB/Using_IndexedDB
> Yonathan Randolph
Received on Monday, 19 March 2012 19:32:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:39 UTC