Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)

On Sat, May 22, 2010 at 3:58 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Fri, May 21, 2010 at 11:42 PM, <bugzilla@jessica.w3.org> wrote:
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9793
>>
>>           Summary: Allow dates and floating point numbers in keys
>>           Product: WebAppsWG
>>           Version: unspecified
>>          Platform: All
>>        OS/Version: All
>>            Status: NEW
>>          Severity: normal
>>          Priority: P2
>>         Component: Indexed Database API
>>        AssignedTo: nikunj.mehta@oracle.com
>>        ReportedBy: pablo.castro@microsoft.com
>>         QAContact: member-webapi-cvs@w3.org
>>                CC: mike@w3.org, public-webapps@w3.org
>>
>>
>> Currently the spec requires the values referenced by the key path to be
>> integers or strings. I strongly believe that we should also allow dates
>> and
>> floating point numbers (am I missing any other important types?). While
>> dates
>> and floating point numbers alone are not good for a primary key, they are
>> important for non-unique indexes and as part of a composite key, allowing
>> for
>> things such as scanning in temporal order.
>>
>> This is the change I'd like to propose:
>>
>> Section "3.1.1 Keys" of the currently published draft reads:
>>
>> -------------------------------------
>> In order to efficiently retrieve records stored in an indexed database, a
>> user
>> agent needs to organize each record by its key. Conforming user agents
>> must
>> support the use of values of IDL data types [WEBIDL] DOMString and long as
>> well
>> as the value null as keys.
>>
>> For purposes of comparison, a DOMString key is always evaluated higher
>> than any
>> long key. Moreover, null always evaluates lower than any DOMString or long
>> key.
>> -------------------------------------
>>
>> New proposed text:
>>
>> -------------------------------------
>> In order to efficiently retrieve records stored in an indexed database, a
>> user
>> agent needs to organize each record by its key. Conforming user agents
>> must
>> support the use of values of IDL data types [WEBIDL] DOMString, long,
>> float,
>> and the Date JavaScript object
>
> We really need to decide, once and for all, whether or not IndexedDB is
> going to be tied to JavaScript or not.  The two major reasons to do so are
> the lack of date in WebIDL and keyPath.
> KeyPath may be tricky to spec in a way that would work for any language
> without cutting out a lot of flexibility.  In order to keep what we're
> speccing sane, it will probably need to be a pretty small subset of what's
> possible in JavaScript and thus even browsers will likely need to roll their
> own parser and such to support it.  (If we do decide to depend on
> JavaScript, it should enable some really neat things with the keyPath as
> well.)
> The HTML spec defines its own date type, but does not specify sort order at
> all.  I started a thread on this a bit ago (subject: "[IndexedDB/WebIDL]
> Dates + Sorting (WAS: Detailed comments for the current draft)") but it only
> got one response [3].

Note that a Date type for WebIDL doesn't really affect things a whole
lot for the interfaces in IndexedDB though. The relevant functions all
take 'any' as type though, so we'll still have to describe in prose
what types are permitted. I don't think this makes IndexedDB depend on
javascript though.

What WebIDL would need, and what has been discussed in the past, is
some type of "compound types". I.e. that you could specify that an
argument can be "a date, an integer, a float or a string".

As for the keyPath issue. The way the spec stands now (where I think
it intends not to allow full expressions), I don't think it really
depends on Javascript. It does depend on the language having some way
to represent structured data. I.e. that the language can hold
something like:

{ foo: "bar",
  complex: { p1: "hello", p2: "world"} }

I'm not really sure how you would return a value like that to
Objective-C. How does WebKit intend to deal with that in APIs where
this issue already exist, such as postMessage?

/ Jonas

Received on Monday, 24 May 2010 20:22:33 UTC