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

On Thu, Jun 3, 2010 at 6:39 PM, Pablo Castro <Pablo.Castro@microsoft.com>wrote:

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

It feels a little odd having our spec reference something in another spec
that hasn't yet been written....but I'm not personally against doing this.
 Until it's specced in WebIDL we should definitely have some non-normative
text saying that we're emulating JavaScript's date behavior for now and that
the actual spec is pending.


>
> Thanks
> -pablo
>
> [1] http://www.mail-archive.com/public-webapps@w3.org/msg08939.html
>
>