On Thu, Oct 13, 2011 at 11:27 AM, Israel Hilerio <[email protected]> wrote: > On Thursday, October 13, 2011 12:15 AM, Jonas Sicking wrote: >>On Wednesday, October 12, 2011, Israel Hilerio <[email protected]> wrote: >>> On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote: >>>> On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio <[email protected]> >>>> 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
