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

Received on Friday, 2 September 2011 10:33:55 UTC