incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guby <guby.m...@gmail.com>
Subject Re: Loading another object to return in a view!
Date Sun, 13 Apr 2008 00:33:37 GMT
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? 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.

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
View raw message