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

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].


Even though no one is currently considering implementing this outside of
JavaScript land and even though it'll limit us some and making speccing
harder, I think it'd be a mistake to depend on JavaScript.  And, as far as I
can tell, the whole point of WebIDL is to not depend on one single language.
 And I can't think of any others that do.

It'd be great to hear from others on the matter.


> , as well as the value null as keys.
>
> For purposes of comparison, all DOMString values are evaluated as greater
> than
> long, float, and Date values; Date values are evaluated as greater than
> long
> and float values; and long and float values are evaluated by their numeric
> value with no need to separate them by type. Moreover, null always
> evaluates
> less than any other key value that is a non-null value. For the particular
> case
> of floating point numbers, the value NaN is not allowed.
> -------------------------------------
>
> I realize that it's weird to have Date as a JavaScript object and the rest
> as
> Web IDL types, but there doesn't seem to be any reference to Date() in Web
> IDL,
> and I don't want to leave it out just because it's not there.
>
> Last time we discussed this topic Nikunj wasn't sure if this was the right
> time, but there was support [1] [2] and no pushback. Assuming we're still
> there, then Eliot (who'll start helping Nikunj with editing) can
> incorporate it
> into the spec.
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0353.html
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0664.html


[3] http://www.mail-archive.com/public-webapps@w3.org/msg08411.html