RE: [indexeddb] Compound Key support for Primary Keys and Indexes

On Friday, September 02, 2011 3:33 AM, Hans Wennborg wrote:
> -----Original Message-----
> From: Hans Wennborg [mailto:hwennborg@google.com]
> Sent: Friday, September 02, 2011 3:33 AM
> To: Israel Hilerio
> Cc: public-webapps@w3.org; Jim Wordelman; Dany Joly; Adam
> Herchenroether; Victor Ngo
> Subject: Re: [indexeddb] Compound Key support for Primary Keys and
> Indexes
> 
> On Tue, Aug 30, 2011 at 9:44 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > Thanks for the feedback.  Answers inline.
> >
> > Israel
> >
> > On Tuesday, August 30, 2011 9:10 AM, Hans Wennborg wrote:
> >> On Sat, Aug 27, 2011 at 1:00 AM, Israel Hilerio
> >> <israelh@microsoft.com>
> >> wrote:
> >> > We looked at the spec to see what it would take to be able to
> >> > support
> >> multi-column keys on primary keys & indexes and we found some
> >> inconsistencies that need to be addressed.  Below is our
> >> proposal/assumptions on how to constrain the problem and what needs
> >> to be updated in the spec to support this:
> >> >
> >> > . Cursors are automatically sorted in ascending order but they can
> >> > be
> >> retrieved in descending order depending on the value passed to the
> >> IDBObjectStore.createIndex.  In other words, all of the attributes
> >> that make up the index or the primary key will share the same
> >> direction.  The default direction will match the single index case.
> >>
> >> I'm not sure I'm following. What does "The default direction will
> >> match the single index case."? And how does the parameters passed to
> >> IDBObjectStore.createIndex affect the direction of cursors?
> >
> > The concern is that compound indexes or keys could have conflicting
> sorting directions.  For example imagine the following list:
> >
> > FirstName1, LastName10
> > FirstName2, LastName9
> > FirstName3, LastName8
> > FirstName4, LastName7
> >
> > In this case, property1 is FirstName and property2 is LastName.  If we were
> to sort using the property1 you will get a different ordered list than if we
> were to sort using property2.  We're suggesting that we use the first property
> in the compound index or key to define the default sort.
> 
> But http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#key-
> construct
> already defines the ordering for all types of keys, including compound ones?
> So in your example they would be sorted as (FirstName1, LastName10),
> (FirstName2, LastName9), (FirstName3, LastName8), (FirstName4,
> LastName7).
> 
> >> > . KeyRanges will act on the first element of the compound key (i.e.
> >> > the first
> >> column).
> >>
> >> Why? Compound keys are just another key type; shouldn't one be able
> >> to specify a KeyRange with compound keys as lower and upper and
> >> expect it to work as with other keys?
> >>
> >
> > You are correct!  The concern was the complexity this would introduce into
> the KeyRange mechanism.  In other words, defining the flexibility for a
> keyRange to be defined and allow each property to be individually
> parameterized could lead to situations in which one property in compound
> index can be defined to be ascending while another property could be
> defined to be descending.  That is the reason we were trying to scope the
> behavior to the first property in the compound index or key.
> 
> I still don't understand the problem. The ordering of keys is defined,
> including for array keys. A key range specifies a range of keys. I don't
> understand what "situations in which one property in compound index can
> be defined to be ascending while another property could be defined to be
> descending" refers to?
> 
>  - Hans

Thanks for the clarifications.  The point we wanted to ensure was that there was no ability to specify a different sort ordering on compound key paths.  If we agree this is not part of the plan then we're okay the way things are in the spec.

Israel

Received on Monday, 12 September 2011 21:01:25 UTC