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.
>
> / Jonas
>
Received on Tuesday, 8 March 2011 23:03:24 UTC