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 <[EMAIL PROTECTED]> wrote: > Async, in most languages, is decidedly not trivial. > > On Fri, Oct 3, 2008 at 12:37 AM, Troy Kruthoff <[EMAIL PROTECTED]> 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 <[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 >>>> >>>> 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
