W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] What happens when the version changes?

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 18 May 2010 08:09:26 -0700
Message-ID: <AANLkTikgKgTbx_Yyi6aWIJfGZXgXMSKB_dnhRl4OFiZz@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, public-webapps WG <public-webapps@w3.org>
On Tue, May 18, 2010 at 3:54 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Tue, May 18, 2010 at 11:04 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tue, May 18, 2010 at 2:42 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> > What happens to existing connections that were opened against the
>> > original
>> > database version (once the DB has been updated)?
>>
>> Once a call to setVersion() has happened, any existing connections
>> will forever fail all requests with a WRONG_VERSION_ERR.
>
> Ahh!  Got it.
>
>>
>> I guess you
>> could argue that if the upgrade transaction is rolled back then we
>> could "reenable" existing connections. However this just seems to be
>> an optimization for an edge case and just adds needless complexity, so
>> I don't think we should do it.
>
> I don't care all that much, but I don't really see this as adding that much
> complexity.  I'd be weakly in favor of an aborted upgrade not requiring
> re-connection.

The complexity I'm concerned about is for the application developers.
I bet most of them will not properly add error handlers to all of
their requests checking for this error. The result is that I suspect
that any tab that gets "shut out" due to a version upgrade will likely
behave strangely. (However this is better than data corruption).

But if we then start allowing requests to go through after having
denyed a bunch of them, then I'd be worried that the tab will corrupt
its own data.

That is why I was thinking that once we've shut someone out, it might
be better to keep it that way.

In general, I tend to operate under the assumption that people are
likely to not add error handlers in most cases, but instead assume
that their requests will always go through.

/ Jonas
Received on Tuesday, 18 May 2010 15:18:24 GMT

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