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 --
smime.p7s
Description: S/MIME cryptographic signature
