Re: [IndexedDB] Spec changes for international language support

On 18 March 2011 19:29, Pablo Castro <> wrote:

> From: []
> On Behalf Of Keean Schupke
> Sent: Friday, March 18, 2011 1:53 AM
> >> See my proposal in another thread. The basic idea is to copy BDB. Have a
> primary index that is based on an integer, something primitive and fast.
> Allow secondary indexes which use a callback to generate a binary index key.
> IDB shifts the complexity out into a library. Common use cases can be
> provided (a hash of all fields in the object, internationalised
> bidirectional lexicographic etc...), but the user is free to write their own
> for less usual cases (for example indexing by the last word in a name string
> to order by surname).
> I agree with Jeremy's comments on the other thread for this. Having the
> callback mechanism definitely sounds interesting but there are a ton of
> common cases that we can solve by just taking a language identifier, I'm not
> sure we want to make people work hard to get something that's already
> supported in most systems. The idea of having a callback to compute the
> index value feels incremental to this, so we could take on it later on
> without disrupting the explicit international collation stuff.

The idea would be to provide pre-defined implementations of the callback for
common use cases, then it is just as simple to register a callback as set
any other option. All this means to the API is you pass a function instead
of a string. It also is better for modularity as all the code relating to
the sort order is kept in the callback functions.

The difference comes down to something like:




So more than just setting a property like the first case, where presumably
all the ordering code is mixed in with the indexing code, the second case
encapsulates all the ordering code in the function returned from the
execution of order_lexicographic('us'). This function would represent a
mapping from the object being indexed to a binary blob that is the actual
stored index data.

So doing it this was does not necessarily make things harder, and it
improves encapsulation, the type-safety, and the flexibility of the API.


Received on Saturday, 19 March 2011 03:17:41 UTC