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

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