- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 19 Mar 2012 12:31:44 -0700
- 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 it. 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