From: jor...@google.com [mailto:jor...@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 <jo...@sicking.cc> wrote: >> On Wed, Aug 11, 2010 at 11:28 PM, Pablo Castro >> <pablo.cas...@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.
