W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Joshua Bell <jsbell@chromium.org>
Date: Wed, 11 Jan 2012 12:42:28 -0800
Message-ID: <CAD649j4XcJ8PpjE4DP4WtVCgkMP=qHAc5pB6qENUMDfpNfH1+Q@mail.gmail.com>
To: public-webapps@w3.org
On Wed, Jan 11, 2012 at 12:40 PM, Joshua Bell <jsbell@chromium.org> wrote:

> 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.
>

To be clear, in Chromium the *algorithm* aborts, leaving the value
unchanged. The request and transaction carry on just fine.


> 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.
>>
>>
>
Received on Wednesday, 11 January 2012 20:49:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT