couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: View generation
Date Fri, 21 Nov 2008 18:27:53 GMT
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.

> 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

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.

> 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.

Chris Anderson

View raw message