- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 16 Aug 2010 16:02:41 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Pablo Castro <Pablo.Castro@microsoft.com>, Mikeal Rogers <mikeal.rogers@gmail.com>, public-webapps WG <public-webapps@w3.org>
On Mon, Aug 16, 2010 at 2:20 AM, Jeremy Orlow <jorlow@chromium.org> wrote: >> >> However I think it's very rare that this will be needed. And there are >> >> ways to somewhat work around it by using separate databases. So I >> >> would probably say that lets keep it database-wide for now, and >> >> reconsider in version 2. >> > >> > On the other hand, is there any reason not to make it >> > per-objectStore/index? >> > As far as I can tell, it should actually be fairly light weight form an >> > API >> > point of view: we can just add it as an optional parameter to >> > createObjectStore/createIndex. From an implementation point of view, I >> > really don't see this being much overhead either. So maybe we should >> > just >> > do it? >> >> I don't feel very strongly. Though I'd want to check that this is >> actually pretty easy to do implementation wise. Given that I think >> this is a low-value feature, I'd want to make sure it's low-cost too. > > How will we "check"? And should we really be basing decisions off of what's > easiest to do implementation wise? And is this truly a low value feature? By "check" I meant talk to Ben and Shawn who actually knows how our implementation works in detail. So the result is that in our current architecture we can't support different collations for different objectStores. We can support changing collation in an existing database though. It will be a very slow operation, but it's needed to avoid forcing authors to delete an existing database and recreate a new one with a new collation. By "low value" I mean that no one has presented a use case that requires it. >> > The alternative is to add a function within setVersion to set the >> > language >> > which actually seems less elegant. >> >> I don't understand what you mean by this. > > Have a setLanguage method on IDBDatabase that can only be called from within > a setVersion transaction. In the same way removeObjectStore and company can > only be called within a setVersion transaction. That would work. So effectively this function would modify all the data in all the objectStores and indexes such that it's now sorted according to the new collation. The 'success' event is fired after all data has been updated. Any requests made after the setLanguage call will see the modified data. Is that the idea? / Jonas
Received on Monday, 16 August 2010 23:03:36 UTC