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

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