Re: Associating users and comments

[Troy Kruthoff]

Threading bad, agreed.

Async good and more trivial.



On Oct 2, 2008, at 1:07 PM, Ayende Rahien wrote:

-- troy

The problem here is not IPC, it is latency. And having to do parallel reads tends to be non trivial in many client scenarios (having to do explicit

thread management, not good).

On Thu, Oct 2, 2008 at 11:04 PM, Chris Anderson <[EMAIL PROTECTED]> wrote:

On Thu, Oct 2, 2008 at 12:49 PM, Alan Bell
<[EMAIL PROTECTED]> wrote:

Jeremy Wall wrote:

Or you can create a last 5 posts for users view. There is nothing wrong

with

that.

But you can't can you? You could create a view of posts for a user and retrieve the top 5 rows, but you can't control a documents presence in the view based on the number of other documents that may or may not be

in the view already I think. Maybe I am being overly pedantic here!

to requote myself:

Alternatively, how would I have it return only 5 Paste's max for each

user?

can't really do that in one request... a request to the map per human
with

would do it.

and to follow up, I agree with Jeremy when he says:

startkey = ["097337c75773737022bb4e8cd3a92140 "]&endkey=["097337c75773737022bb4e8cd3a92140",{}]&count=6

Alternatively, you can do the 20 roundabouts but in parallel so the

latency

hit is only the longest roundtrip. CouchDB shouldn't have any problem

with a

lot of simultaneous reads at once.

CouchDB handle concurrency well, and shies away from query options
that would negatively impact it's ability to do so. That means cases
like this push more work to the client. Maybe the IPC overhead

guess we'll learn as we go along.


--
Chris Anderson
http://jchris.mfdz.com

outstrips the lower load on CouchDB's internals, maybe it doesn't... I

smime.p7s
Description: S/MIME cryptographic signature