This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9793 - Allow dates and floating point numbers in keys
Summary: Allow dates and floating point numbers in keys
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Eliot Graff
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-21 22:42 UTC by Pablo Castro
Modified: 2010-06-20 15:13 UTC (History)
4 users (show)

See Also:


Attachments

Description Pablo Castro 2010-05-21 22:42:45 UTC
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, 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
Comment 1 Jonas Sicking (Not reading bugmail) 2010-05-21 23:19:51 UTC
I agree that this makes sense. There's always a hazard when doing equality checks on floats, but that's no more an effort here than anywhere else as I understand it.
Comment 2 Jeremy Orlow 2010-06-02 13:48:33 UTC
This sounds fine to me, but longer term we'll need to spec dates enough that we don't depend on the JavaScript notion of dates [1].  Sam has said he'll work on incorporating this into WebIDL [2], so I don't think there's anything to be done at the moment.

[1] http://www.mail-archive.com/public-webapps@w3.org/msg08936.html
[2] http://www.mail-archive.com/public-webapps@w3.org/msg08939.html
Comment 3 Eliot Graff 2010-06-20 15:13:41 UTC
Changed per text with minor editing to language to increase readability.

Thanks for the clear proposed text.