couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <jch...@apache.org>
Subject Re: Associating users and comments
Date Thu, 02 Oct 2008 22:09:48 GMT
Here's a "trivial" implementation of threading for CouchDB access
written in Ruby.

So far it's been reliable.

http://github.com/atduskgreg/slipcover/tree/master

On Thu, Oct 2, 2008 at 2:40 PM, Ayende Rahien <ayende@ayende.com> wrote:
> 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
>>>>
>>>>
>>
>



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

Mime
View raw message