Re: [IndexedDB] Multi-value keys

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:37:03 UTC