W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

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

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Thu, 3 Jun 2010 17:39:24 +0000
To: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Eliot Graff <eliotgra@microsoft.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>
Message-ID: <F753B2C401114141B426DB383C8885E04DAE68AB@TK5EX14MBXC128.redmond.corp.microsoft.com>

From: Jeremy Orlow
Sent: Tuesday, May 25, 2010 6:54 AM

>> On Mon, May 24, 2010 at 9:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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.

Closing the loop on this one. Now that we agreed to add some language to WebIDL for the Date type [1], should we go ahead and make this change to the spec? I can ask Eliot to do it so we can close this one if folks feel it makes sense.

Thanks
-pablo

[1] http://www.mail-archive.com/public-webapps@w3.org/msg08939.html
Received on Thursday, 3 June 2010 17:40:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT