W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [indexeddb] Calling IDBDatabase.close inside onupgradeneeded handler

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 13 Oct 2011 15:26:31 -0700
Message-ID: <CA+c2ei-pSrsdbuoXfutRoEg063DnSOhX4AXntTYnBTsDqH80Kw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT