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

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.
>
> What WebIDL would need, and what has been discussed in the past, is
> some type of "compound types". I.e. that you could specify that an
> argument can be "a date, an integer, a float or a string".
>

Agreed.  But that compound type will depend on a proper date type being
specced.  I imagine WebIDL can borrow text from the HTML spec for the
parsing, but (most importantly) we need it to specify sorting.  (Hopefully
in a way similar or equal to JavaScript.)

As for the keyPath issue. The way the spec stands now (where I think
> it intends not to allow full expressions), I don't think it really
> depends on Javascript. It does depend on the language having some way
> to represent structured data. I.e. that the language can hold
> something like:
>
> { foo: "bar",
>  complex: { p1: "hello", p2: "world"} }
>

You're right.  Depending on JavaScript makes things easier, but it doesn't
necessarily depend on it.  I guess we should bug this, though.  (Adding to
my list.)