On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro <pablo.cas...@microsoft.com>wrote:
> > From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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 <jo...@sicking.cc> wrote: > >> On Mon, Mar 7, 2011 at 10:43 PM, Jeremy Orlow <jor...@chromium.org> > wrote: > >> > On Fri, Jan 21, 2011 at 1:41 AM, Jeremy Orlow <jor...@chromium.org> > wrote: > >> >> > >> >> On Thu, Jan 20, 2011 at 6:29 PM, Tab Atkins Jr. < > jackalm...@gmail.com> > >> >> wrote: > >> >>> > >> >>> On Thu, Jan 20, 2011 at 10:12 AM, Keean Schupke <ke...@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
