Re: [IndexedDB] Languages for collation

On Tue, Aug 17, 2010 at 12:02 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.


Come to think of it, it's the same for us.  But that's not to say that it
couldn't be done another way.  And implementation should be a very minor
worry for us.  But given that we think multiple databases will be a good
work around, I'm fine sticking with a per-database setting as Pablo
originally proposed.


> 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?
>

I'm not married to any of the particulars, but yeah that is the general
idea.