- From: Israel Hilerio <israelh@microsoft.com>
- Date: Wed, 7 Dec 2011 22:39:32 +0000
- To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
- CC: Jim Wordelman <jaword@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>, Victor Ngo <vicngo@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Saturday, December 03, 2011 9:28 PM, Jonas Sicking wrote: > Subject: Re: [indexeddb] error value of open request after aborting > VERSION_CHANGE transaction inside an onupgradeneeded handler > > On Thu, Dec 1, 2011 at 7:16 PM, Israel Hilerio <israelh@microsoft.com> > wrote: > > On Tuesday, November 22, 2011 5:30 PM, Israel Hilerio wrote: > >>Subject: [indexeddb] error value of open request after aborting > >>VERSION_CHANGE transaction inside an onupgradeneeded handler > >> > >>What should be the value of the error attribute on the open request > >>after > a VERSION_CHANGE transaction is aborted? We're thinking it should be > AbortError independent of whether the >transaction is aborted > programmatically or due to a system failure. > >> > >>Do you guys agree? > >> > >>Israel > > > > Should I take the silence to mean we're in agreement :-) > > Either that, or set it to whatever error caused the transaction to be aborted. > So the request error would be set to the same as the transaction error. > > / Jonas We believe that the error granularity you outlined above is more appropriate to be surfaced on the IDBTransaction.onabort or IDBTransaction.onerror handlers. It doesn't seem to be very useful on the IDBOpenRequest associated with the IDBFactory.open method. Also, at the open IDBOpenRequest level, it doesn't seem to matter the reason why the transaction failed, all it matters is that it failed. That is one of the reasons we were suggesting to only surface the AbortError at that level. The other reason is that this will signal the difference in behavior between the IDBOpenRequest and the IDBRequest. Israel
Received on Wednesday, 7 December 2011 22:40:16 UTC