couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davis" <>
Subject Re: Associating users and comments
Date Thu, 02 Oct 2008 03:42:20 GMT

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,

On Wed, Oct 1, 2008 at 11:12 PM, Ben Bangert <> wrote:
> On Oct 1, 2008, at 8:00 PM, Chris Anderson wrote:
>> 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,})
>  } 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

View raw message