- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 12 Oct 2011 16:21:00 -0700
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>
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
Received on Wednesday, 12 October 2011 23:21:57 UTC