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

Re: [IndexedDB] Compound and multiple keys

From: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 7 Mar 2011 22:43:50 -0800
Message-ID: <AANLkTinvg72tKt_371iDmYDfrWsKo7Dyzx5S0KAtuGmt@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Keean Schupke <keean@fry-it.com>, Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
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?

Thanks,
J
Received on Tuesday, 8 March 2011 06:44:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT