- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Wed, 9 Mar 2011 01:55:38 +0000
- To: Keean Schupke <keean@fry-it.com>, Jeremy Orlow <jorlow@chromium.org>
- CC: Jonas Sicking <jonas@sicking.cc>, Tab Atkins Jr. <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Keean Schupke
Sent: Tuesday, March 08, 2011 3:03 PM
>> No objections here.
>>
>> Keean.
>>
>> On 8 March 2011 21:14, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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.
Option A is pretty well understood, I like that one.
For option B, at some point we had a debate on whether when indexing an array value we should consider it a single key value or we should unfold it into multiple index records. The first option makes it very similar to A in that an array is just a composite value (it is quite a bit more painful to implement...), the second option is interesting in that allows for new scenarios such as objects with an array for tags, where you want to look up by tag (even after doing options A and B as currently defined, in order support multiple tags you'd need a second store that keeps the tags + key for the objects you want to tag). Is there any interest in that scenario?
Thanks
-pablo
Received on Wednesday, 9 March 2011 01:56:14 UTC