New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support stale=update_after #6

Merged
merged 1 commit into from Aug 13, 2011

Conversation

Projects
None yet
3 participants
@kocolosk
Member

kocolosk commented Aug 12, 2011

I know this one follows CouchDB's implementation for the single server case, but I'd like to see a version that triggers a view build by simply sending a message to the view group instead of spawning a process to request an updated group. The process isn't going to do anything with the group, it's just going to sit there taking up resources while the view builds. Adding a cast handler to the view group should allow us to accept an unlimited number of stale=update_after requests during the lifetime of a build without crashing.

@davisp

This comment has been minimized.

Show comment
Hide comment
@davisp

davisp Aug 12, 2011

Member

Good point. I'll remember to swap out my copy of the spawn(fun() -> get_state(Pid, Latest) end) type call for a cast message. it'd even clean up some client code as well.

Member

davisp commented Aug 12, 2011

Good point. I'll remember to swap out my copy of the spawn(fun() -> get_state(Pid, Latest) end) type call for a cast message. it'd even clean up some client code as well.

@rnewson

This comment has been minimized.

Show comment
Hide comment
@rnewson

rnewson Aug 12, 2011

Member

Good idea.

Member

rnewson commented Aug 12, 2011

Good idea.

@rnewson

This comment has been minimized.

Show comment
Hide comment
@rnewson

rnewson Aug 12, 2011

Member

You also need cloudant/bigcouch@52ff89f for bigcouch which is the HEAD of 10941-stale-update-after based off master, but should cherry-pick easily.

Member

rnewson commented Aug 12, 2011

You also need cloudant/bigcouch@52ff89f for bigcouch which is the HEAD of 10941-stale-update-after based off master, but should cherry-pick easily.

@kocolosk

This comment has been minimized.

Show comment
Hide comment
@kocolosk

kocolosk Aug 12, 2011

Member

I merged that commit to master and also squashed the work in this request down to a single commit. I think it's ready to go in, just trying to decide what makes the most sense in re pull requests. This pull request will be automatically closed if a) we merge the branch or b) we rebase on top of master and then do the fast-forward merge. I don't think a simple cherry-pick will do the automatic close thing.

Member

kocolosk commented Aug 12, 2011

I merged that commit to master and also squashed the work in this request down to a single commit. I think it's ready to go in, just trying to decide what makes the most sense in re pull requests. This pull request will be automatically closed if a) we merge the branch or b) we rebase on top of master and then do the fast-forward merge. I don't think a simple cherry-pick will do the automatic close thing.

@kocolosk

This comment has been minimized.

Show comment
Hide comment
@kocolosk

kocolosk Aug 12, 2011

Member

I went ahead and rebased to get the auto-close. Seems silly to generate a merge commit for a one-commit branch.

Member

kocolosk commented Aug 12, 2011

I went ahead and rebased to get the auto-close. Seems silly to generate a merge commit for a one-commit branch.

@kocolosk kocolosk merged commit 01958ba into master Aug 13, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment