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  
enough.

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.

Sho

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


> Cheers
> Jan
> --