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

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.