RE: [indexeddb] Do we need to support keyPaths with an empty string?
On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
Given the changes that Jonas made to the spec, on which other scenarios do we
expect developers to specify a keyPath with an empty string (i.e. keyPath =
)?
Do we still need to support this or can we just throw if this takes place. I
reopened bug #14985 [1] to reflect this. Jonas or anyone else could you
please
clarify?
Israel
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985
Any updates! I expect this to apply to all of the following scenarios:
var obj = { keyPath : null };
var obj = { keyPath : undefined };
var obj = { keyPath : };
If you guys agree, we can update the spec.
Israel
Re: [indexeddb] Do we need to support keyPaths with an empty string?
On Wed, Jan 18, 2012 at 11:30 AM, Israel Hilerio isra...@microsoft.comwrote:
On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
Given the changes that Jonas made to the spec, on which other scenarios
do we
expect developers to specify a keyPath with an empty string (i.e.
keyPath = )?
Do we still need to support this or can we just throw if this takes
place. I
reopened bug #14985 [1] to reflect this. Jonas or anyone else could you
please
clarify?
Israel
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985
Any updates! I expect this to apply to all of the following scenarios:
var obj = { keyPath : null };
var obj = { keyPath : undefined };
var obj = { keyPath : };
If I'm reading your concern right, the wording in the spec (and Jonas'
comment in the bug) hints at the scenario of using the value as its own key
for object stores as long as autoIncrement is false, e.g.
store = db.createObjectStore(my-store, {keyPath: });
store.put(abc); // same as store.put(abc, abc)
store.put([123]); // same as store.put([123], [123]);
store.put({foo: bar}); // keyPath yields value which is not a valid key,
so should throw
Chrome supports this today (apart from a known bug with the error case).
One scenario would be using an object store to implement a Set, which seems
like a valid use case if not particularly exciting.
RfC: Draft of New Charter for the HyBi WG
Hi All, The HyBi WG chairs created a new charter for the HyBi wg and asked their WG for comments [1]. The draft charter includes the following: [[ The following extensions and optimizations are currently in scope: 1. Define a per-frame compression extension to improve the bandwidth usage. 2. Define a multiplexing extension to improve the scalability of the WebSocket protocol 3. Define timeout-handling capabilities to reduce the chattiness of the protocol ]] Since the HyBi WG expects to continue its liaison with WebApps, the HyBi chairs would appreciate any comments WebApps has on their draft charter [1] as well as feedback on whether they should work on other extensions or optimizations. Additionally, we would also appreciate feed on whether we expect these extensions to have any impact on the WebSocket API itself. -AB [1] http://www.ietf.org/mail-archive/web/hybi/current/msg09393.html
RE: [indexeddb] Do we need to support keyPaths with an empty string?
Joshua,
We did some testing in FF and Chrome and found different behaviors:
*With keyPath: undefined or null. In this scenario, FF and Chrome
fails when executing add(foobar) without a key value. However, Chrome allows
you to add a valid key value or an object if you specify a key (i.e.
add(foobar,1); ). Firefox doesn't work in either case. You end up with what
appears to be a broken Object Store.
*With keyPath: or empty string. In this scenario, FF fails when
executing add(foobar) without a key, but succeeds if you supply a key value.
It doesn't matter if the value being added is a valid key or an object. Chrome
succeeds when executing add(foobar) but fails when the value being added is
an object (i.e. add({foo: bar}); ). Chrome also fails when you specify a key
value even if the value being added is a valid key value (i.e. add(foobar,
1); ).
Given the different behaviors, I wonder if the use case you described below
(i.e. set scenario) is worth supporting. Not supporting keyPath = undefined,
null, and seem to provide a more consistent and clean story. Returning an
exception when a developer creates an Object Store with a keyPath of null,
undefined, or empty string will provide a FailFast API.
What do you think?
Israel
On Wednesday, January 18, 2012 12:08 PM Joshua Bell wrote:
On Wed, Jan 18, 2012 at 11:30 AM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
Given the changes that Jonas made to the spec, on which other scenarios do we
expect developers to specify a keyPath with an empty string (i.e. keyPath =
)?
Do we still need to support this or can we just throw if this takes place. I
reopened bug #14985 [1] to reflect this. Jonas or anyone else could you
please
clarify?
Israel
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985
Any updates! I expect this to apply to all of the following scenarios:
var obj = { keyPath : null };
var obj = { keyPath : undefined };
var obj = { keyPath : };
If I'm reading your concern right, the wording in the spec (and Jonas' comment
in the bug) hints at the scenario of using the value as its own key for object
stores as long as autoIncrement is false, e.g.
store = db.createObjectStore(my-store, {keyPath: });
store.put(abc); // same as store.put(abc, abc)
store.put([123]); // same as store.put([123], [123]);
store.put({foo: bar}); // keyPath yields value which is not a valid key, so
should throw
Chrome supports this today (apart from a known bug with the error case).
One scenario would be using an object store to implement a Set, which seems
like a valid use case if not particularly exciting.
Re: [indexeddb] Do we need to support keyPaths with an empty string?
On Wed, Jan 18, 2012 at 1:16 PM, Israel Hilerio isra...@microsoft.com wrote: We did some testing in FF and Chrome and found different behaviors: Hi Israel, Which version of Firefox did you test with? Thanks, Ben
RE: [indexeddb] Do we need to support keyPaths with an empty string?
On Wednesday, January 18, 2012 1:27 PM, ben turner wrote: On Wed, Jan 18, 2012 at 1:16 PM, Israel Hilerio isra...@microsoft.com wrote: We did some testing in FF and Chrome and found different behaviors: Hi Israel, Which version of Firefox did you test with? Thanks, Ben We tested on Firefox 8.0.1 Israel
Re: [indexeddb] Do we need to support keyPaths with an empty string?
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.com wrote: We tested on Firefox 8.0.1 Ah, ok. We made lots of big changes to key handling that will be in 11 I think. If you're curious I would recommend retesting with an aurora build from https://www.mozilla.org/en-US/firefox/aurora. Thanks for the info! -Ben
Re: [indexeddb] Do we need to support keyPaths with an empty string?
On Wed, Jan 18, 2012 at 1:51 PM, ben turner bent.mozi...@gmail.com wrote: On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.com wrote: We tested on Firefox 8.0.1 Ah, ok. We made lots of big changes to key handling that will be in 11 I think. If you're curious I would recommend retesting with an aurora build from https://www.mozilla.org/en-US/firefox/aurora. Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 (beta) and 18 (canary).
RE: [indexeddb] Do we need to support keyPaths with an empty string?
Based on our retesting of Aurora and Canary, this is the behavior we're seeing: When a null or undefined keyPath is provided to the createObjectStore API, you can add values to an Object Store as long as a key is specified during the execution of the Add API. Not providing a key for the Add API will throw a DATA_ERR. Providing an empty string keyPath to the createObjectStore produces the opposite behavior. The Add API works as long as you don't provide any value for the key. I'm assuming that the value is used as the key value and that is the reason why using an object as the value fails. This difference in behavior seems strange to me. I would expect the behavior to be the same between a keyPath value of empty string, null, and undefined. How do you explain developers the reasons for the differences? Is this the behavior we want to support moving forward? Israel On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote: On Wed, Jan 18, 2012 at 1:51 PM, ben turner bent.mozi...@gmail.commailto:bent.mozi...@gmail.com wrote: On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.commailto:isra...@microsoft.com wrote: We tested on Firefox 8.0.1 Ah, ok. We made lots of big changes to key handling that will be in 11 I think. If you're curious I would recommend retesting with an aurora build from https://www.mozilla.org/en-US/firefox/aurora. Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 (beta) and 18 (canary).
