- 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>
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 UTC