incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bradford Winfrey <>
Subject Re: when to use another document and when not to?
Date Tue, 22 Jul 2008 17:37:24 GMT

Don't apologize it's better for everyone using couch to get these out in the open so that
as the community grows there's an idea of expectation and how to work through these problems.
 I think it's great to have a thread like this for people to use as a resource.  Especially
now that we have benchmarks.


----- Original Message ----
From: Sho Fukamachi <>
Sent: Tuesday, July 22, 2008 12:19:35 PM
Subject: Re: when to use another document and when not to?

On 23/07/2008, at 2:33 AM, Jan Lehnardt wrote:
>> The outcome of the previous discussion on this thread seemed to be  
>> in favour of the use of a "followers" table which I thought was a  
>> pretty bad idea in CouchDB. I'd love to hear some defences of that,  
>> maybe someone can tell me what I'm missing...
> Your gut feeling was correct, it is a bad idea.

Jan! I'd been hoping you'd comment.

Care to elaborate a bit? I would really appreciate your insight!

The simple situation is this: users can subscribe to other users. We  
need to be able to query in both directions - ie, starting with a  
known user, get the user records he is subscribed to - and the other  
direction, starting with a user, get the user records of those  
subscribed to him.

I had actually been bending to the "followers" table a little, after  
doing some benchmarks and finding that 99% of the time just  
individually GET-ing the list of users (in either direction) from a  
list of IDs obtained from the followers table was going to be fast  

I would *like* to place subscriptions in one or the other but just  
cannot think of how it is possible to write the views *in both  
directions* once it's stuck in a user, and I end up having to do the  
GET loop anyway.

Would love to hear your views : ) Please let me know if I am not  
making any sense.


PS sorry all those who are sick of this thread ....

> Cheers
> Jan
> --

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