Re: [indexeddb] Keypath attribute lookup question

On Mon, Nov 14, 2011 at 5:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> What I think we should do is to get index values from the structured
> clone of X. There at least two advantages of this:
>
> 1. The code to get index values can run on the database thread of the
> IDB implementation. This enables a more parallel implementation.
> 2. It means that .add/.put/.update is consistent with .createIndex
>
> .createIndex always has to get values from the structured clone since
> at the time when it runs, the structured clones stored in the database
> is the only thing we have.
>

Agreed re: parallel implementation - Chrome is already doing this work
(error checking, keypath evaluation, index updating) in a separate process
from one running the page's JavaScript, so this is of practical as well as
theoretical importance for us. Sounds good.

I do however think that we should simply state that getting the index
> values will use the normal method for looking up properties on JS
> objects. This includes walking the prototype chain. Practically
> speaking this only makes a difference on host objects like Files and
> ArrayBuffers since plain JS objects loose their prototype during
> structured clones.
>

Since I lurk on es-discuss, I have to nitpick that this leaves spec
ambiguity around Object.prototype and async operations. The HTML5 spec
sayeth re: structured cloning of objects: "Let output be a newly
constructed empty Object object" - that implies (to me) that the clone's
prototype is Object.prototype.

Here's where the ambiguity comes in - assume async API usage:

my_store.createIndex("some index", "foo");
...
Object.prototype.foo = 1;
my_store.put(new Object);
Object.prototype.foo = 2;
// what indexkey was used?

One possibility would be to modify the structured clone algorithm (!) to
mandate that the Object has no prototype (i.e. what you get from
Object.create(null)) but that would probably surprise developers since the
resulting objects wouldn't have toString() and friends. Scoped to just IDB
we could explicitly exclude Object.prototype

This should alleviate Israels concern about being able to index on
> Blob.size or File.name.
>
> In any case, I filed
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14830 on specifying
> behavior here explicitly one way or another.
>

Awesome, thanks!