On Friday, September 02, 2011 3:33 AM, Hans Wennborg wrote: > -----Original Message----- > From: Hans Wennborg [mailto:[email protected]] > Sent: Friday, September 02, 2011 3:33 AM > To: Israel Hilerio > Cc: [email protected]; 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 <[email protected]> > 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 > >> <[email protected]> > >> 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
