RE: [IndexedDB] Languages for collation

From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy Orlow
Sent: Thursday, August 12, 2010 3:36 AM

>> On Thu, Aug 12, 2010 at 11:19 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wed, Aug 11, 2010 at 11:28 PM, Pablo Castro
>> <Pablo.Castro@microsoft.com> wrote:
>> > We had some discussions about collation algorithms and such in the past, but I don't think we have settled on the language aspect of it. In order to have stores and indexes sort character-based keys in a way that is consistent with users' expectations we'll have to take indication in the API of what language we should use to collate strings.
>> >
>> > Trying to take a minimalist approach, we could add an optional parameter on the database open call that indicates the language to use (e.g. "en" or "en-UK", etc.). If the language is not specified and the database does not exist, then we can use the current browser/OS language to create the database. If not specified and database already exists, then use the one it's already there (this accommodates the fact that a user may be able to change their default language in the browser/OS after the database has been created using the default). If the language is specified and the database already exists and the specified language is not the one the database has then we'll throw an exception (same behavior as with "description", although we have that one in flight right now as well).
>> >
>> > We should probably also add a read-only attribute to the database object that exposes the language.
>> >
>> > If this works for folks I can write a proposal for the specific changes to the spec.
>> If we make it part of the database open call, then that makes it
>> impossible to change the sorting order of an existing database, no?
>> This seems like it could be a problem. I.e. it quite possible that an
>> application will want to allow the user to change the sorting
>> language, for example when changing the language of the UI.
>>
>> One solution would be to allow language to be set as part of the
>> setVersion call.
>>
>> Whether it's per-database or more fine grained I think it absolutely must be part of setVersion.  Changing the language will be a very heavyweight operation that'll require a similar level of isolation to "schema" changes of the database.  (Not sure how I missed this point of Pablo's original email.)

Yes, changing the collection would effectively mean re-creating all the stores and indexes. At a very minimum it needs to be a setVersion thing. I also don't think it would be too crazy to not support changing collations period. In the unusual case where a user must absolutely do this, it can be done by creating a separate database and copying the data over using the APIs.

Received on Friday, 13 August 2010 00:35:18 UTC