On Mon, Sep 12, 2011 at 2:00 PM, Israel Hilerio <[email protected]> wrote: > 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.
Yup. As things stand keys are always sorted in ascending direction in both indexes and objectStores. And when the key is a compound value, each component is sorted in ascending direction. We might want to look into enabling more complex use cases at a later point, but for now I think we should stick with the current solution. / Jonas
