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

There's another edge case here - what happens on a put (etc) request to an
object store with a key generator when the object store's key path does not
yield a value, yet the algorithm below exits without changing the value.

Sample:

store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement:
true});
request = store.put("value");

3.2.5 for "put" has this error case "The object store uses in-line keys and
the result of evaluating the object store's key path yields a value and
that value is not a valid key." resulting in a DataError. In this case,
"4.7 Steps for extracting a key from a value using a key path" says "no
value is returned", so that error case doesn't apply.

"5.1 Object Store Storage Operation" step 2 is: "If store uses a key
generator and key is undefined, set key to the next generated key. If store
also uses in-line keys, then set the property in value pointed to by
store's key path to the new value for key."

Per the algorithm below, the value would not change. (Another example would
be a keyPath of "length" and putting [1,2,3])

Chrome's current behavior in this case is that the put (etc) call returns
without raising an error, but an error event is raised against the request
indicating that the value could not be applied. This would imply having the
algorithm below return a success/failure indicator and having the steps in
5.1 abort if the set fails.

Thoughts?

On Wed, Jan 11, 2012 at 4:36 PM, Israel Hilerio <israelh@microsoft.com>wrote:

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