Ben, I think what you're running into is the CouchDB != SQL impedance mismatch. Its not overt and I see you're thinking about this, but I still manage to not see my RDBMS prejudices after working on this for a couple months.
The biggest thing is I think we're pretty much indoctrinated into thinking "Normalize until it's painful, denormalize untill it works." Your first question about "Only give me pastes where someone has a paste" would probably be accomplished by storing a "has_paste" or "num_pastes" attribute on the human document. I'd probably go with "has_paste" because it would be a one time update. I haven't groked the reduce step well enough to give you a concrete answer on the "Give me max 5 posts" question, but the general idea is that you'd look at keys to make sure you're dealing with one post and then only return the 5 pastes you want. I think most people would agree with me that the least 'understood/properly used/leveraged' ability of couch is the reduce step. In a random thought that's happening right now, I wonder if a lot of us are looking at the reduce step as a magical SQL join. (even if not overtly) There are definite plans for providing a intersection/union type of syntax for multiple indexes. Ie, "give me key/values in index blah V index foo" I see that Chris managed to provide a reduce for the first question which is good. The second answer is missing part of the question. As in I think Ben was asking "Give me a list of users and their top 5 posts" which != "Give me user and top 5 posts". So far I think its clear we need better reduce docs. Also, I'm thinking tomorrow might be a good day to start thinking about view intersection/union syntax. Anyone that cares feel free to pipe up on IRC or the ML. I don't see the implementation being difficult given a decent method for specifying the sub queries. Forgive the randomness, Paul On Wed, Oct 1, 2008 at 11:12 PM, Ben Bangert <[EMAIL PROTECTED]> wrote: > On Oct 1, 2008, at 8:00 PM, Chris Anderson wrote: > >> http://wiki.apache.org/couchdb/Views >> >> The reduce docs are somewhat lacking... > > I did read those.... let me be more specific, I have a few documents with > key/value pairs like so: > > _id "097337c75773737022bb4e8cd3a92140" > _rev "3161423366" > created "2008-10-01T19:40:25Z" > last_login "2008-10-01T19:40:25Z" > name "Joe" > type "Human" > > _id "3fefb1f90316b029b7937c01964e4fd8" > _rev "2184850695" > created "2008-10-01T19:40:25Z" > last_login "2008-10-01T19:40:25Z" > name "Fred Smith" > type "Human" > username "fsmith" > > _id "dd7d49e84929231c4384216e8dfbb133" > _rev "1337790890" > code "This is a sample" > created "2008-10-01T19:40:25Z" > human_id "097337c75773737022bb4e8cd3a92140" > language "text" > title "Sample 1" > type "Paste" > > > Now, I can easily use the view collation to have a list of all the users and > their 'Paste's that go with them, no prob. I get how the keys influence sort > and such by having a map function like so (to get me the info I want for > each one): > > function(doc) { > if (doc.type == 'Human') { > emit([doc._id, 0], {type:doc.type, name:doc.name}) > } else if (doc.type == 'Paste') { > emit([doc.human_id, 1], doc); > } > } > > Now, how would I filter this list, so that I don't get all the Humans with > zero paste's filed for them? Ie, I only want the human row in the result set > if there's going to be a Paste type row following it. > > Alternatively, how would I have it return only 5 Paste's max for each user? > > Thanks, > Ben
