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

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

From: Israel Hilerio <israelh@microsoft.com>
Date: Thu, 13 Oct 2011 18:27:50 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Victor Ngo <vicngo@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3F4C9D90@TK5EX14MBXC117.redmond.corp.microsoft.com>
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.

Received on Thursday, 13 October 2011 18:28:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC