W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] Compound and multiple keys

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 8 Mar 2011 13:14:21 -0800
Message-ID: <AANLkTi=HWYU5qBPg5t9yY_r+cpqpeosdsZg7BbCb-2yd@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Keean Schupke <keean@fry-it.com>, Webapps WG <public-webapps@w3.org>
On Mon, Mar 7, 2011 at 10:43 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Fri, Jan 21, 2011 at 1:41 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> On Thu, Jan 20, 2011 at 6:29 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>>> On Thu, Jan 20, 2011 at 10:12 AM, Keean Schupke <keean@fry-it.com> wrote:
>>> > Compound primary keys are commonly used afaik.
>>> Indeed.  It's one of the common themes in the debate between natural
>>> and synthetic keys.
>> Fair enough.
>> Should we allow explicit compound keys?  I.e myOS.put({...}, ['first
>> name', 'last name'])?  I feel pretty strongly that if we do, we should
>> require this be specified up-front when creating the objectStore.  I.e. add
>> some additional parameter to the optional options object.  Otherwise, we'll
>> force implementations to handle variable compound keys for just this one
>> case, which seems kind of silly.
>> The other option is to just disallow them.
> After thinking about it a bunch and talking to others, I'm actually leaning
> towards both option A and B.  Although this will be a little harder for
> implementors, it seems like there are solid reasons why some users would
> want to use A and solid reasons why others would want to use B.
> Any objections to us going that route?

Not from me. If I don't hear objections I'll write up a spec draft and
attach it here before committing to the spec.

/ Jonas
Received on Tuesday, 8 March 2011 21:15:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC