- From: Mikeal Rogers <mikeal.rogers@gmail.com>
- Date: Fri, 18 Jun 2010 23:25:13 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
I'm currently building out the CouchDB API on top of IndexedDB and achieving this particular use case is pretty trivial. I would just process a map function like: function (doc) { doc.names.forEach(function(n){emit(n, 1)})} ; Then I would process that map function and create an index with each key/value and a reference back to the document that was used to create the index. When I pull out the "view" I would optionally also pull out the originating document from the other objectStore. I think it's simple enough to do on top of the existing API that I wouldn't want to exclude Jonas' use case, or complicate things by specifying sorting of JSON style arrays inside the string sorting algorithm. -Mikeal On Fri, Jun 18, 2010 at 7:13 PM, Jeremy Orlow <jorlow@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. > > 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. > J > On Fri, Jun 18, 2010 at 4:08 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> Hi All, >> >> One thing that (if I'm reading the spec correctly) is currently >> impossible is to create multi-valued keys. Consider for example an >> object store containing objects like: >> >> { firstName: "Sven", lastName: "Svensson", age: 57 } >> { firstName: "Benny", lastName: "Andersson", age: 63 } >> { firstName: "Benny", lastName: "Bedrup", age: 9 } >> >> It is easy to create an index which lets you quickly find everyone >> with a given firstName or a given lastName. However it doesn't seem >> possible to create an index that finds everyone with a given firstName >> *and* lastName, or sort the list of people based on firstName and then >> lastName. >> >> The best thing you could do is to concatenate the firstname and >> lastname and insert a ascii-null character in between and then use >> that as a key in the index. However this doesn't work if firstName or >> lastName can contain null characters. Also, if you want to be able to >> sort by firstName and then age there is no good way to put all the >> information into a single string while having sorting work. >> >> Generally the way this is done in SQL is that you can create an index >> on multiple columns. That way each row has multiple values as the key, >> and sorting is first done on the first value, then the second, then >> the third etc. >> >> However since we don't really have columns we can't use that exact >> solution. Instead, the way we could allow multiple values is to add an >> additional type as keys: Arrays. >> >> That way you can use ["Sven", 57], ["Benny", 63] and ["Benny", 9] as >> keys for the respective objects above. This would allow sorting and >> searching on firstName and age. >> >> The way that array keys would be compared is that we'd first compare >> the first item in both arrays. If they are different the arrays are >> ordered the same way as the two first-values are order. If they are >> the same you look at the second value and so on. If you reach the end >> of one array before finding a difference then that array is sorted >> before the other. >> >> We'd also have to define the order if an array is compared to a >> non-array value. It doesn't really matter what we say here, but I >> propose that we put all array after all non-arrays. >> >> Note that I don't think we need to allow arrays to contain arrays. >> That just seems to add complication without adding additional >> functionality. >> >> Let me know what you think. >> >> / Jonas >> > >
Received on Saturday, 19 June 2010 06:25:40 UTC