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 Sun, 13 Apr 2008 01:35:16 GMT
2008/4/13, Guby <guby.mail@gmail.com>:
>
> Hi Ralf!
> Thanks for your reply
>
> Approach #3 is basically the one I am using, only that the post_id-user_id
> document is the comment.
> In your approach #3, wouldn't I have to do another trip to the database
> for the blogpost there too?


Yes.

I can't really so a way to use f.ex view collation to fetch both the
> relational document (comment) and the blog post itself with a
> post_id-user_id document when the user id isn't also specified in the blog
> post itself. Because then they can't share a common key.
>
> I hope this can somehow be solved with map/reduce later on.


On restropect, only when a reduce is capable of saying
just-remove-this-key; perhaps by returning 'null' ?

Greetings,
Ralf.


Best regards
> Sebastian
>
>
> On Apr 12, 2008, at 8:53 PM, Ralf Nieuwenhuijsen wrote:
>
>  ------=_Part_34546_33031881.1208044393514
> > Content-Type: text/plain; charset=ISO-8859-1
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > 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>
> > > >
> > >
>

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