incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Nieuwenhuijsen" <ralf.nieuwenhuij...@gmail.com>
Subject Re: Loading another object to return in a view!
Date Sat, 12 Apr 2008 23:53:13 GMT
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/
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message