couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ayende Rahien" <aye...@ayende.com>
Subject Re: Associating users and comments
Date Thu, 02 Oct 2008 21:40:54 GMT
Async, in most languages, is decidedly not trivial.

On Fri, Oct 3, 2008 at 12:37 AM, Troy Kruthoff <tkruthoff@blit.com> wrote:

> Threading bad, agreed.
>
> Async good and more trivial.
>
> -- troy
>
> On Oct 2, 2008, at 1:07 PM, Ayende Rahien wrote:
>
>  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 <jchris@apache.org>
>> wrote:
>>
>>  On Thu, Oct 2, 2008 at 12:49 PM, Alan Bell
>>> <alan.bell@theopenlearningcentre.com> 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
>>>
>>> startkey=["097337c75773737022bb4e8cd3a92140"]&endkey=["097337c75773737022bb4e8cd3a92140",{}]&count=6
>>> would do it.
>>>
>>> and to follow up, I agree with Jeremy when he says:
>>>
>>>  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
>>> outstrips the lower load on CouchDB's internals, maybe it doesn't... I
>>> guess we'll learn as we go along.
>>>
>>>
>>> --
>>> Chris Anderson
>>> http://jchris.mfdz.com
>>>
>>>
>

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