Re: [IndexedDB] KeyPaths and missing properties.

>> So you'd have to pass in the javascript expression as a string. This
>> certainly works but is more than a little ugly. It also complicates
>> the implementation a good bit since it now has to include a javascript
>> engine. Not a huge issue given that all browsers has one anyway, but
>> feels a bit iffy.
>
> Hm.  I'm looking at the spec, and I can't find where (if anywhere) it talks
> about what's allowed as a key path.  I guess I had assumed that it was
> essentially javascript (or maybe some subset) and that we'd at least need to
> be parsing it anyway.  If we don't adopt this idea because we're worried
> about depending on javascript, then we should spec out the keyPath syntax
> pretty precisely to ensure we don't have such a dependency.
> <snip>

I think the intent of the current syntax is that it's a '.' separated
list of property names. But yes, it definitely needs to be precisely
defined.

>> > I still think it's an interesting idea, though I'm not sold on it.
>> > Especially for the first version of the spec.
>>
>> It seems like there would be a lot of edge cases to define here. First
>> of all, how is the value passed in to this expression? Do we say that
>> it's available through some "value" variable? So that if you want to
>> index on the "foo" property, you pass in an expression like
>> "value.foo"? Or do we want the value to be the global object, so that
>> if you wanted to index on the "foo" property the expression would
>> simply be "foo"?
>
> Since we're already talking about requiring that data being inserted into
> objectStores with a keyPath (for its primary key or in one of its indexes),
> setting it as the global object seems reasonable.  And it matches what's
> currently specced for the simple 1 entityStore entry to 1 index entry (per
> index) case.

You also have to specify how the value is returned. I.e. does the
expression need to end with 'return X'? Or do we index on the result
of the value returned from the last executed expression?

Also, I think that if the value is the global object, then I declaring
variables inside the expression modifies the value as global variables
are set on the global object.

>> Also, what happens if the javascript expression modifies the value?
>> Does the implementation have to clone the value before calling each
>> "index expression"?
>
> In order of how much I like the idea:
> 1) In an ideal world, we'd spec it to be read only, but I'm not sure if most
> JS engines have an easy way to do something like that.
> 2) Another possibility is to make the order in which indexes are processed
> deterministic.  That way, if someone does modify it, it'll at least
> be consistent.
> 3) Cloning is another possibility, but it seems like it'd have a performance
> impact.  Maybe optimized implementations could copy-on-write it, though?

I think 1 and 3 suffers from the same problem of not being something
that JS engines usually need to do, and so likely isn't implemented.
In both cases you have to be able to mark an object graph such that
you take special action if it's modified.

And for 2, do you do the structured clone before or after you run the
keyPath expressions? Not until after you've created the structured
clone will you know if the value can even be stored.

In short, I'd like to see a comprehensive proposal :) Then I could
take that to the JS team and ask if it's implementable.

/ Jonas

Received on Thursday, 20 May 2010 23:40:08 UTC