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

Great!  I will work with Eliot to unify the language and update the spec.

Israel

On Wednesday, January 11, 2012 3:45 PM, Joshua Bell wrote:
On Wed, Jan 11, 2012 at 3:17 PM, Israel Hilerio <israelh@microsoft.com<mailto:israelh@microsoft.com>> wrote:
We updated Section 3.1.3 with examples to capture the behavior you are seeing in IE.

Ah, I missed this, looking for normative text. :)

Based on this section, if the attribute doesn't exists and there is an autogen is set to true the attribute is added to the structure and can be used to access the generated value. The use case for this is to be able to auto-generate a key value by the system in a well-defined attribute. This allows devs to access their primary keys from a well-known attribute.  This is easier than having to add the attribute yourself with an empty value before adding the object. This was agreed on a previous email thread last year.

I agree with you that we should probably add a section with "steps for assigning a key to a value using a key path."  However, I would change step #4 and add #8.5 to reflect the approach described in section 3.1.3 and #9 to reflect that you can't add attributes to entities which are not objects.  In my mind this is how the new section should look like:

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 create the attribute and assign it an empty object.  If error creating the attribute then skip the remaining steps, /value/ is not modified, and throw a DOMException of type InvalidStateError.
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/
8.5. If /object/ does not have an attribute named /attribute/, then create the attribute.  If error creating the attribute then skip the remaining steps, /value/ is not modified, and throw a DOMException of type InvalidStateError.
9. If /object/ has an attribute named /attribute/ which is not modifiable, then
skip the remaining steps, /value/ is not modified, and throw a DOMException of type InvalidStateError.
10. Set an attribute named /attribute/ on /object/ with the value /key/.

What do you think?

Overall looks good to me. Obviously needs to be renumbered. Steps 4 and 8.5 talk about first creating an attribute, then later then assigning it a value. In contrast, step 10 phrases it as a single operation ("set an attribute named /attribute/ on /object/ with the value /key/"). We should unify the language; I'm not sure if there's precedent for one step vs. two step attribute assignment.

Israel
On Wednesday, January 11, 2012 12:42 PM, Joshua Bell wrote:
On Wed, Jan 11, 2012 at 12:40 PM, Joshua Bell <jsbell@chromium.org<mailto: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<mailto: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<mailto:dave.null@w3.org>
       ReportedBy: jsbell@chromium.org<mailto:jsbell@chromium.org>
        QAContact: member-webapi-cvs@w3.org<mailto:member-webapi-cvs@w3.org>
               CC: mike@w3.org<mailto:mike@w3.org>, public-webapps@w3.org<mailto: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.