This should now be fixed in editor drafts.
On Sat, Mar 3, 2012 at 2:58 AM, Jonas Sicking jo...@sicking.cc wrote:
Oh, I missed Joshua's last email. So it seems everyone is in agreement. I'll
make the edits and then close the bug.
/ Jonas
On Saturday, March 3, 2012, Jonas Sicking wrote:
On Thu, Mar 1, 2012 at 8:20 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
What should we do for the following scenario:
store = db.createObjectStore(store);
index = store.createIndex(index, x, { multiEntry: true });
store.add({ x: [a, b, {}, c] }, 1);
index.count().onsuccess =
We agree with FF's implementation. It seems to match the current sparse index
concept where values that can't be indexed are automatically ignored. However,
this doesn't prevent them from being added.
Israel
On Friday, March 02, 2012 8:59 AM, Joshua Bell wrote:
On Thu, Mar 1, 2012 at 8:20 PM,
I should clarify; Chromium will not actually alert 0, but would raise an
exception (unless caught, of course)
Israel's comment makes me wonder if there's some disagreement or confusion
about this clause of the spec:
If there are any indexes referencing this object store whose key path is a
I think I know where the misunderstanding is coming from. There was an email
thread [1] in which Jonas proposed this change and we had agreed to the
following:
I propose that we remove the requirement that we have today that if
an indexed property exists, it has to contain a valid value.
From: Israel Hilerio isra...@microsoft.com
Unfortunately, we didn’t update the spec to reflect this agreement.
You or I could open a bug to ensure the spec is updated to capture
this change.
Yes, better get it into the spec :-)
About the behavior itself, FWIW, I think it's a reasonable
I’ve created a bug to track this issue:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211
Israel
On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote:
From: Israel Hilerio isra...@microsoft.commailto:isra...@microsoft.com
Unfortunately, we didn’t update the spec to reflect this
Thanks. Based on this, I agree that in the multiEntry scenario at the start
of this thread, 3 is the more consistent result.
On Fri, Mar 2, 2012 at 5:29 PM, Israel Hilerio isra...@microsoft.comwrote:
I’ve created a bug to track this issue:
Crap, we need to better about filing bugs :-)
Yes, my understanding is that there was agreement to update the spec such
that if evaluating and index's keyPath does not yield a valid key that does
not affect weather the value is inserted in the objectStore.
In other words, indexes do not add
Oh, I missed Joshua's last email. So it seems everyone is in agreement.
I'll make the edits and then close the bug.
/ Jonas
On Saturday, March 3, 2012, Jonas Sicking wrote:
Crap, we need to better about filing bugs :-)
Yes, my understanding is that there was agreement to update the spec such
10 matches
Mail list logo
