http://www.w3.org/Bugs/Public/show_bug.cgi?id=11348
Summary: [IndexedDB] Overhaul of the event model Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We talked about this for a while at TPAC. Here's what I think we agreed upon at the time: * All events should propagate from the IDBRequest to the IDBTransaction to the IDBDatabase. * For error events, preventDefault must be called in order to avoid a transaction aborting. (When you use onerror, you'd of course use false to do so.) * If you throw within an event handler, the transaction will abort. (Catch errors that you don't want to implicitly abort the transaction.) * The success event will be non-bubbling (because having onsuccess on IDBTransaction and IDBDatabase would be confusing). * The error event should be added to IDBTransaction and IDBDatabase and should bubble. * createObjectStore should remain sync and simply abort the transaction on errors (which are pretty much constrained to quota and internal errors). * createIndex is the same, except that indexes with a uniqueness constraint and existing data that doesn't satisfy it will present another (and more common) case that'll cause the transaction to abort. The spec should have a red note that reminds people of this. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.