couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davis" <>
Subject Re: View generation
Date Fri, 21 Nov 2008 18:42:52 GMT
On Fri, Nov 21, 2008 at 1:27 PM, Chris Anderson <> wrote:
> On Fri, Nov 21, 2008 at 8:25 AM, Paul Davis <> wrote:
>> Chris,
>> I've got the next 5 days or so free to do some work. I was thinking
>> about tearing into the view generation, but I wanted to check and see
>> if you had any pressing plans for it so we're not duplicating work.
> I don't think I'll be jumping on that code this week, but there's some
> interesting stuff in the pipeline to know about.
>> Also, if you had any more thoughts on how to implement things that I
>> should start thinking about let me know.
> So I met with Francesco from Erlang Training and Consulting, and
> described to him the selective receive loop thing going on in the
> view_group_server. He said "ahhh", because he's seen that pattern lots
> of times, and then said "you never want to be dealing with raw ! and
> receive". He's sending me some materials about the pattern, so when I
> have that, maybe I'll know how to build it in the classic Erlang way.
> Feel free to do any implementation you'd like, but I might suddenly
> have a flash of insight once I read his material.

Sweet. Unless I have some sudden insight into gen_server and how to
make that wait appropriately without that receive loop I won't change
the mechanics very much.

>> Also, we never quite resolved the what to do during the initial build.
>> IIRC, it basically boiled down to: Wait no matter what during the
>> first build vs. never wait.
> I'm fine to post it to the list (just gonna go ahead and cross post
> it), but I'm still pretty sure that it's not really possible to do the
> "never wait" b/c you'll definitely have to wait a tiny bit, if the
> view is almost up to date. (And how can you tell if the view is very
> out of date vs only a little? Even on initial generation, you may only
> have 10 documents in the db, so doing something other than waiting is
> gonna be more confusing that helpful.)
> I think the robust solution is to support a status call, that tells
> you the last sequence id of the view, as well as the current sequence
> id of database. If an application commonly encounters long view build
> times than developers could use the status call to provide progress
> indicators.
> I don't think it's good to have a normal view request magically turn
> into a status request, in lieu of waiting on the view build.

Very good points. I was wondering about how the mechanics of the API
would work with the status and turn around times. Your argument here
has pretty much convinced me that the stale=ok and status=true is
probably the best solution to the problem.

>> What do you think about posting the
>> question for a vote on the dev list to resolve it? I think either
>> implementation would be fine as long as we're sure that's what people
>> expect from the feature.
> Matt Aimonetti at QCon in SF this week requested an interesting
> feature: Etags on view results. In thinking this feature through I
> realized that it requires the same infrastructure that "update-false"
> and view status need. Etags would be a function of the view-group
> signature, a canonical representation of the view server params, and
> the last-sequence-id that the fully-up-to-date view was emitted to at.
> So the view state server should be able to return that information as
> part of the status request, for internal (etag) use as well as for the
> explicit status api.

I'm not sure on the specifics of ETags, but it sounds like you've
covered all the bases that would be required here.

> --
> Chris Anderson

Anyone else out there have thoughts on view generation?

View raw message