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
