Just a small note, I might be mistaken, but this could be done more cleanly
using the reduce/combiner functionality that is  not implemented yet.

Greetings,
Ralf

2008/4/13, Ralf Nieuwenhuijsen <ralf.nieuwenhuijsen@gmail.com>:
>
> I'm no expert, but to me it seems you have some options
>
> 1) fetch all posts seperately. (that would be a nice cumaltive roundtrip
> penalty)
> 2) store comments in user-profile, instead of separately (annoying)
> 3) do the relational thing (sorry!), and store a unique document for each
> relation
>
> Solution 3 would mean you put documents for each comment as such:
>
> {
>   _id: "post_id-user-id"
>   postid: 9334,
>   userid: 3494,
>   type: "post-user-relationship"
> }
>
> By using post-id-user-id together as the user id you have no risk of
> duplicating this information. If it doesn't exist you create the document,
> if it does exist you are just updating it to the exact same values.
>
> With this separate relationship document you should be able to pull trick
> #3 for both use-cases.
>
> But it's getting really uncomfortable to use such a relational approach
> here.
>
> Greetings,
> Ralf
>
> 2008/4/12, Guby <guby.mail@gmail.com>:
> >
> > Hi Christopher!
> > I read your post back when you posted it. It is an interesting read.
> >
> > I'll try to explain my problem using your blog metaphor, maybe that
> > makes it clearer.
> >
> > First:
> > My first attempt was your approach number 1. Storing all the comments in
> > the post itself. But I am already getting some 409 Conflicts in my worker
> > processes (concurrency conflicts), and that is probably going to increase
> > once I get users on my system, so that doesn't seem like a really good
> > approach.
> >
> > Approach #3 is good when you want to get a post and all its associated
> > comments.
> > I, on the other hand, am trying to get all the posts that a certain user
> > has commented on. If I wanted to use view collation the way you describe I
> > would have to store the comment in the post or at least some token that
> > indicates that a certain user has commented on a post, and then we are back
> > to approach #1 which we are trying to avoid... or am I missing something?
> >
> > Best regards
> > Sebastian
> >
> >
> > On Apr 12, 2008, at 2:22 PM, Christopher Lenz wrote:
> >
> >  On 12.04.2008, at 18:13, Guby wrote:
> > >
> > > > My first attempt was to store the user ratings in the entry itself,
> > > > and then use a for loop in the view to map the entry to each user ID, but to
> > > > store if the user has read the entry or not I would then have to load the
> > > > whole entry with all its ratings change the value of one flag, and then save
> > > > it all back. Seems like I would be loading an awful lot of information and
> > > > wasting a lot of resources(?). Maybe I am trying to save computer cycles at
> > > > the wrong place. What I ended up doing instead is more a relational database
> > > > approach:
> > > >
> > > > Now I have my entry document which only is the entry itself, and
> > > > then user_entry documents that have references to the entry, stores the
> > > > users rating and a flag wether or not it has been read and if the rating
> > > > passed the users threshold or not. It works perfectly until I want to go
> > > > from a list of user_entries to a list of entries. If I load a list of
> > > > user_entries that have a certain rating I have to make a seperate call to
> > > > the database to load each entry! That is why I tried creating a view that
> > > > would check the user_entry and the return the qualified entries directly...
> > > >
> > >
> > > I you haven't read it already, I'd recommend looking at a blog post of
> > > mine that explores this stuff:
> > >
> > >  <http://www.cmlenz.net/archives/2007/10/couchdb-joins>
> > >
> > > Cheers,
> > > --
> > > Christopher Lenz
> > >  cmlenz at gmx.de
> > >  http://www.cmlenz.net/
> > >
> > >
> >
>