We've talked about this off and on for a while now, but given that we've
made a decision on how to handle compound keys, I think we can finally come
to closure on this.
There are several basic use cases.
1) You have a "names" field in the object that you're storing and you want
to be able to search for any one of the names in the same index. For
example, I can search for "Rose" and I'll get people whose first, middle, or
even last name is Rose.
2) Similarly, you might have multiple phone numbers that apply to a single
person and thus you'd want to search all of them at the same time.
3) You're implementing something (for example Gmail) which allows multiple
labels to correspond to a particular object, and where you want to be able
to efficiently look it up.
All of these can be worked around by creating another ObjectStore, and this
is what one would do in SQL (create another table). But given that this is
a common thing to do, I think we should add it to the API itself.
I talked to Jonas and Ben Turner a bit about this, and I believe we were
leaning towards adding a new option to createIndex to enable this. The best
name we could come up with was "multi index" (so multiIndex?) but maybe
someone else can come up with something better?
Thanks,
Jeremy