Re: [IndexedDB] Multi-value keys

On Friday, June 18, 2010, Mikeal Rogers <> wrote:
> I would like to see null and bool types in arrays as well.
> null is useful if it is assured to sort before any other type, bool
> types are useful if you want to use integers in the same sort as you
> want bools and therefor could not just use 0 and 1 instead.
> If you add all these new types (null, bool, int, float, date) as valid
> entries in the array and define a sort order I don't see why you
> wouldn't just add them as valid key types, it doesn't seem like it
> would be much extra work and it's definitely useful.
> objects would be hard, I'm +1 on punting them as key types.

Why would you need bools in the same sort as integers? I.e. what is
the use case, what type of data are you sorting?

In general I don't see much use in mixing types, though we can't
prevent it so we need to define it. But I'd like to avoid introducing
more complexity than needed to deal with it.

/ Jonas

> On Fri, Jun 18, 2010 at 5:36 PM, Jonas Sicking <> wrote:
>> On Fri, Jun 18, 2010 at 5:18 PM, Pablo Castro
>> <> wrote:
>>> +1 on composite keys in general. The alternative to the proposal below would be to have the actual key path specification include multiple members (e.g. db.createObjectStore("foo", ["a", "b"])). I like the proposal below as well, I just wonder if having the key path specification (that's external to the object) indicate which members are keys would be less invasive for scenarios where you already have javascript objects you're getting from a web service or something and want to store them "as is".
>> My intention was for now to *just* add Arrays (of strings, ints,
>> floats and dates) as a valid key type. No other changes at this point.
>> This would mean that you would be allowed to pass an array as the
>> 'key' argument to objectStore.add or have a keyPath point to a member
>> that is an array. But also in the future other means might be possible
>> too. See [1].
>> For the case that you bring up (and which I used in my example), where
>> you have several separate members that you want to index on, I for now
>> was going to defer that to the thread that I started yesterday [1].
>> That would allow you pick out several separate members and use them as
>> index.
>> Though it certainly is an interesting idea to allow multiple keyPaths.
>> This would likely be more performant than falling back to the method
>> in [1].
>> [1]
>> / Jonas

Received on Saturday, 19 June 2010 01:46:05 UTC