- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 13 Oct 2011 15:26:31 -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 Thu, Oct 13, 2011 at 11:27 AM, Israel Hilerio <israelh@microsoft.com> wrote: > On Thursday, October 13, 2011 12:15 AM, Jonas Sicking wrote: >>On Wednesday, October 12, 2011, Israel Hilerio <israelh@microsoft.com> wrote: >>> 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. >> >>My thinking was that we should only fire the success event if we can really hand the success handler a >opened database. That seems to make the open handler easiest to implement for the web page. >> >>If we do fire the success handler in this case, what would we hand the handler as result? Null? A closed >database? Something else? >> >>/ Jonas > > We were thinking that we would give back a closed db (i.e. closed connection and a closePending flag set to true). We believe that this mimics the intent of the developer when they closed the db inside of their onupgradeneeded handler. Ok, that works for me. / Jonas
Received on Thursday, 13 October 2011 22:27:29 UTC