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

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 18 May 2010 16:23:04 +0100
Message-ID: <AANLkTinqttTW6BQUHgq6Pr9Wx9QaRpyD5GO-_vh18JVj@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
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 4:09 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.
>

Ahhh.  I see.  You're assuming that some method calls are synchronous but
cannot block (like what you proposed in your other email, but not like
what's currently specced)....?  Well, if that's the case, then I completely
agree with you. Even if not, I think I've proven to myself that it's good to
spec it that way to keep our options open in the future.

J

P.S. I completely agree with your philosophies on users handling errors,
keeping things less confusing and more deterministic, etc.
Received on Tuesday, 18 May 2010 15:24:21 GMT

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