- From: Israel Hilerio <israelh@microsoft.com>
- Date: Wed, 12 Oct 2011 23:27:33 +0000
- To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>
On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote: > On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio <israelh@microsoft.com> > wrote: > > If a db connection is closed inside the onupgradeneeded handler, section 4.1 > step #8 states that we should return an ABORT_ERR and abort steps. This > implies that the transaction should fail. Since today, the db is closed after all > requests have been processed, we don't see the reason why we would return > an error instead of just allowing the db connection to follow its natural > course. The worst that can happen is that we return a handle to a closed db, > which is what the developer intended. > > > > Should we remove this constraint and not error out on this particular case > (i.e. calling db.close from onupgradeneeded)? Or, are there reasons to keep > this logic around? > > I agree, we should not abort the VERSION_CHANGE transaction. > > It'd still make sense to fire an "error" event on the request returned from > indexeddb.open though, after the transaction is committed. This since the > database wasn't successfully opened. > > / Jonas Couldn't you make the case that it was successfully opened and therefore you were able to run the upgrade logic. However, the developer chose to close it before returning from the handler. This will provide us a pattern to upgrade DBs without having to keep the db opened or a handle around. It will also help devs differentiate this pattern from a real db open problem. Israel
Received on Wednesday, 12 October 2011 23:28:10 UTC