- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 8 Mar 2011 13:14:21 -0800
- 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