W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] Languages for collation

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 16 Aug 2010 16:02:41 -0700
Message-ID: <AANLkTiniwHsP0GbVavXeoRzsAY3bH8TZHyQyLJoh=vmW@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC