Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

I thought this issue was theoretical when I filed it, but it appears to be
the reason behind the difference in results for IE10 vs. Chrome 17 when
running this test:

http://samples.msdn.microsoft.com/ietestcenter/indexeddb/indexeddb_harness.htm?url=idbobjectstore_add8.htm

If I'm reading the test script right, the IDB implementation is being asked
to assign a key (autogenerated, so a number, say 1) using the key path
"test.obj.key" to a value { property: "data" }

The Chromium/WebKit implementation follows the steps I outlined below.
Namely, at step 4 the algorithm would abort when the value is found to not
have a "test" attribute. If IE10 is passing, then it must be synthesizing
new JS objects as it walks the key path, until it gets to the final step in
the path, yielding something like { property: "data", test: { obj: { key: 1
} } }

Thoughts?

On Thu, Jan 5, 2012 at 1:44 PM, <bugzilla@jessica.w3.org> wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15434
>
>           Summary: [IndexedDB] Detail steps for assigning a key to a
>                    value
>           Product: WebAppsWG
>           Version: unspecified
>          Platform: All
>        OS/Version: All
>            Status: NEW
>          Severity: minor
>          Priority: P2
>         Component: Indexed Database API
>        AssignedTo: dave.null@w3.org
>        ReportedBy: jsbell@chromium.org
>         QAContact: member-webapi-cvs@w3.org
>                CC: mike@w3.org, public-webapps@w3.org
>
>
> In section 5.1 "Object Store Storage Operation", step 2: when a key
> generator
> is used with store with in line keys, the spec says: "set the property in
> value
> pointed to by store's key path to the new value for key"
>
> The "steps for extracting a key from a value using a key path" are called
> out
> explicitly under Algorithms in 4.7. Should the steps for assigning a key
> to a
> value using a key path be similarly documented?
>
> Cribbing from the spec, this could read as:
>
> 4.X Steps for assigning a key to a value using a key path
>
> When taking the steps for assigning a key to a value using a key path, the
> implementation must run the following algorithm. The algorithm takes a key
> path
> named /keyPath/, a key named /key/, and a value named /value/ which may be
> modified by the steps of the algorithm.
>
> 1. If /keyPath/ is the empty string, skip the remaining steps and /value/
> is
> not modified.
> 2. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/.
> 3. If /remainingKeypath/ has a period in it, assign /remainingKeypath/ to
> be
> everything after the first period and assign /attribute/ to be everything
> before that first period. Otherwise, go to step 7.
> 4. If /object/ does not have an attribute named /attribute/, then skip the
> rest
> of these steps and /value/ is not modified.
> 5. Assign /object/ to be the /value/ of the attribute named /attribute/ on
> /object/.
> 6. Go to step 3.
> 7. NOTE: The steps leading here ensure that /remainingKeyPath/ is a single
> attribute name (i.e. string without periods) by this step.
> 8. Let /attribute/ be /remainingKeyPath/
> 9. If /object/ has an attribute named /attribute/ which is not modifiable,
> then
> skip the remaining steps and /value/ is not modified.
> 10. Set an attribute named /attribute/ on /object/ with the value /key/.
>
> Notes:
>
> The above talks in terms of a mutable value. It could be amended to have an
> initial step which produces a clone of the value, which is later returned,
> but
> given how this algorithm is used the difference is not observable, since
> the
> value stored should already be a clone that doesn't have any other
> references.
>
> Step 9 is present in case the key path refers to a "special" property,
> e.g. a
> String/Array length, Blob/File properties, etc.
>
> --
> Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
>