- From: Joshua Bell <jsbell@chromium.org>
- Date: Wed, 11 Jan 2012 12:42:28 -0800
- To: public-webapps@w3.org
- Message-ID: <CAD649j4XcJ8PpjE4DP4WtVCgkMP=qHAc5pB6qENUMDfpNfH1+Q@mail.gmail.com>
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 UTC