- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Fri, 11 Oct 2013 15:44:55 +0200
- To: public-webapps@w3.org
On Wed, Oct 9, 2013, at 21:10, Joshua Bell wrote: > To do this in a backwards compatible way, we could add an option on > open() that, if an upgrade is required, any other connections are forcibly > closed; instead of a "versionchange" event the connections would be sent a > "close" event, similar to the case in [1] > > Open question about whether the close waits on in-flight transactions or > if they are aborted. > > [1] > http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0022.html The problem with options are that "noone" uses them, because it's easier to just do .open(). Just the same problem we'd have with .openOrFail(). Having close as default action on the versionchange is an interesting workaround, but I think it won't be possible to do that change now. Yes, it will make more code suddenly work much better, but it will break some too. If we could do evil, it would be less extreme to only add the db close as default action if you hadn't already put another handler on the versionchange. But that'd be crazy. It is indeed the biggest WTF of IndexedDB, and I'm only certain more people will discover it after long debugging sessions after IDB is started to get used by more people. And sadly, not during development, but when they want to upgrade their already in-production system. We will see more problems coming our way because of this. :) Let's hope as few as possible use raw IDB and rather use more friendly wrapper libraries that get this right. -- Odin Hørthe Omdal odinho@opera.com
Received on Friday, 11 October 2013 13:45:28 UTC