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

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