Re: [IndexedDB] Compound and multiple keys

On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro <Pablo.Castro@microsoft.com>wrote:

>
> 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?
>

Yes.  Once we're settled on this, I'm going to send an email on that.  :-)
 Option b won't get in the way of my proposal.

J