Re: [IndexedDB] Multi-value keys

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.

-Mikeal

On Fri, Jun 18, 2010 at 5:36 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Jun 18, 2010 at 5:18 PM, Pablo Castro
> <Pablo.Castro@microsoft.com> 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] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1094.html
>
> / Jonas
>
>

Received on Saturday, 19 June 2010 00:45:36 UTC