- From: <bugzilla@jessica.w3.org>
- Date: Fri, 19 Nov 2010 11:44:16 +0000
- To: public-webapps@w3.org
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.null@w3.org ReportedBy: jorlow@chromium.org QAContact: member-webapi-cvs@w3.org CC: mike@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.
Received on Friday, 19 November 2010 11:44:21 UTC