On Fri, Jun 18, 2010 at 7:13 PM, Jeremy Orlow <jor...@chromium.org> wrote: > Another possible meaning for arrays is allowing someone to insert multiple > values into an index that point to one object store. For example: > { names: ["Sarah", "Jessica", "Parker"], ...} > { names: ["Bono"], ...} > { names: ["Jonas", "Sicking"], ...} > Then I could look up "Sicking" inside an index with a keyPath of "names" and > find Jonas even though I didn't know whether I was looking for his first > name or last. > I'm not sure whether creating semantics like this (or at least reserving the > possibility for them in the future) is worth not using indexes as Jonas > proposed, but it's worth considering. > > I'm also not so hot on the idea that if I want to index into something I > either need to duplicate/mangle data in order to use keyPath or do explicit > key management (which I'm not so hot on in general). I wonder if we could > define keyPath to take some sort of array like syntax so that your example > could work via a keyPath of "[firstName, lastName]" instead. Of course then > the spec for the keyPath syntax is more complex.
This is what Pablo suggested. Though he suggested the syntax ["firstName", "lastName"] which I think is a better idea as then we won't need to get into parsing strings more than we already are. I agree that duplicating or mangling data is not ideal, which is why I made the suggestion in [1]. I think this is an ok solution for the case when you have a property that contains a list and you want to add each entry to the index. > I'm sold on the need for ways to do composite indexes, but I'm not sure what > the best way to express them will be. The fact that couchDB allows indexing > on arrays definitely makes me lean towards your proposal though, Jonas. Cool! [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1094.html / Jonas