- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 18 May 2010 08:09:26 -0700
- 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 UTC