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

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:****
>
> *From:* jsbell@google.com [mailto:jsbell@google.com] *On Behalf Of *Joshua
> Bell
> *Sent:* Wednesday, January 11, 2012 12:42 PM
> *To:* public-webapps@w3.org
> *Subject:* Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a
> key to a value****
>
> ** **
>
> 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.****
>
> ** **
>
>  ** **
>