This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15796 - Specify how to extract a key when keyPath is an array
Summary: Specify how to extract a key when keyPath is an array
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Jonas Sicking (Not reading bugmail)
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-30 19:39 UTC by Odin Hørthe Omdal
Modified: 2012-03-02 15:42 UTC (History)
3 users (show)

See Also:


Attachments

Description Odin Hørthe Omdal 2012-01-30 19:39:01 UTC
createObjectStore allows us to get a keyPath that is an array[1].

But there is as far as I can tell a lack of explicit mention of the possibility of the keyPath being an array later.

Does it belong in the steps for extracting a key path from a value? [2] Or possibly more fitting, a step up in the hierarchy like the steps for storing a record into and object store.

Anyway, keyPath as Array seems to be well specified for Indexes, both in IDBObjectStore.add [3] and in the steps for storing a record into an object store [4], but not so for keys, AFAICS.


Maybe change step 1 in "steps for storing a record into an object store" from:

> 1. If store does use in-line keys and evaluting store's key path on value
>    does yield a value, then set key to that result.

to:

> 1. If store uses in-line keys and the store's key path is an [Array]
>    then set /tempkey/ to a newly created empty Array. For each item in 
>    the key path [evaluate] the item on value. If this does not yield a
>    value continue to next step. Otherwise add the value to the end of 
>    /tempkey/. When the array is finished set /key/ to /tempkey/.
>
> 2. Else if store does use in-line keys and evaluating store's key path 
>    on value yields a value, then set key to that result.


Possibly changed to clearer and more succinct language :P


1. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabase-createObjectStore-IDBObjectStore-DOMString-name-IDBObjectStoreParameters-optionalParameters
2. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-extracting-a-key-from-a-value-using-a-key-path
3. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBObjectStore-add-IDBRequest-any-value-any-key
4. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-storing-a-record-into-an-object-store
Comment 1 Jonas Sicking (Not reading bugmail) 2012-01-30 21:26:59 UTC
Yeah, I suspect this should be defined in the steps for evaluating a keyPath.

The way that we do this in Firefox is that we evaluate each item in the array individually. If any item fails yield a value which is a valid Key then we abort the whole algorithm and the keyPath-Array does not yield a value. If this is the keyPath for a objectStore then this results in throwing an exception. If this is a keyPath for an index then no entry is added to the index.

Simply skipping the item in the array which did not yield a keyPath doesn't seem correct to me. Consider the following example code:

store = db.createObjectStore("sales", { keyPath: ["prodID", "seller"] });
store.put({ prodID: "gummy-candy", seller: "Sven", quantity: 10});
store.put({ prodID: "chocolate-bar", seller: "Stina", quantity: 5});
store.put({ seller: "Lars", quantity: 5});

The first two entries create keys like: ["gummy-candy", "Sven"] and ["chocolate-bar", "Stina"].

If we were to use ["Lars"] as the key for the last entry, then it'd look like "Lars" was the product ID and that a seller was missing. The right solution is to throw an exception for the last call as we don't have a sensible key to use.
Comment 2 Odin Hørthe Omdal 2012-01-31 09:43:26 UTC
Yes, that was how I envisioned it as well. I see I goofed up in my example proposal; it shouldn't be "continue to next step" but rather "set error attribute ... and terminate the algorithm". :-)

Putting the array-specific parts into the algorithm "steps for extracting a key from a value using a key path" seems a bit wrong too, because you won't be able to just run those steps on a single keyPath. But maybe that's of no value in the spec anyway.

The array-specific looping-part could be put in 3.1.5 Key Path [1], but it seems a bit out of place there as it'd benefit from some more algorithmic steps. That's why I put it in the "steps for storing a record into an object store".

Those steps would at least need some added error handling if the "steps for extracting a key from a value using a key path" handles the keyPath-Array itself.


1. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-evaluate-key-path
Comment 3 Jonas Sicking (Not reading bugmail) 2012-03-02 04:03:15 UTC
I'll take this one.
Comment 4 Jonas Sicking (Not reading bugmail) 2012-03-02 15:42:17 UTC
Done.

I specified it as part of the keyPath evaluation steps since that way it will automatically be specified both when a keypath-array is used in an objectStore, and when a keypath-array is used in an index.