Re: [VOTE] Apache CouchDB new docs proposal
These two projects are orthogonal to each other: Project 1: Getting code/API docs bundled in the source distribution. Project 2: Getting a new website design in place. On Sat, Nov 26, 2011 at 1:36 AM, Marco Monteiro wrote: > Can the first step be to get the docbook api documentation in the repo and > start from that? Any plan that delays that step is not as good. > > On 25 November 2011 23:13, Noah Slater wrote: > > > I seem to be missing the start of this thread. > > > > What are we voting on? > > > > I am happy to lead the way on getting this implemented, and dealing with > > people's requests, and saying no a lot, and all the other things you have > > to do when you're trying to avoid designing by committee. But to do that, > > I'm going to need a designer to help me turn these from mockups into > > working HTML and CSS for a fully functional site, with each page nicely > set > > out. > > > > Copying in kriesse and eegg, on the off chance that either of them have > the > > cycles to devote to this. ;) > > > > On Wed, Nov 23, 2011 at 1:23 PM, Robert Newson > wrote: > > > > > +1 > > > > > > On 23 November 2011 10:31, Dave Cottlehuber wrote: > > > > On 22 November 2011 15:08, Dave Cottlehuber > wrote: > > > > > > > > Sorry, seems none of my dropbox links are working this week. > > > > > > > > Here are the eegg and kriesse versions with links to a couch like I > > > > should be doing …. Gist also updated. > > > > > > > >> Hi devs, > > > >> ## references > > > > > > > > - kriesse [3]: https://github.com/Kriesse/couchdb_web or view at > > > > > > > > > > http://skunkwerks.iriscouch.com/couchdocs/_design/couchdocs/kriesse_couch_web/index.html > > > > - eegg [4]: https://github.com/eegg/couchdb_web or view at > > > > > > > > > > http://skunkwerks.iriscouch.com/couchdocs/_design/couchdocs/eegg_couch_web/index.html > > > > > > > > A+ > > > > Dave > > > > > > > > > >
Re: [VOTE] Apache CouchDB new docs proposal
Can the first step be to get the docbook api documentation in the repo and start from that? Any plan that delays that step is not as good. On 25 November 2011 23:13, Noah Slater wrote: > I seem to be missing the start of this thread. > > What are we voting on? > > I am happy to lead the way on getting this implemented, and dealing with > people's requests, and saying no a lot, and all the other things you have > to do when you're trying to avoid designing by committee. But to do that, > I'm going to need a designer to help me turn these from mockups into > working HTML and CSS for a fully functional site, with each page nicely set > out. > > Copying in kriesse and eegg, on the off chance that either of them have the > cycles to devote to this. ;) > > On Wed, Nov 23, 2011 at 1:23 PM, Robert Newson wrote: > > > +1 > > > > On 23 November 2011 10:31, Dave Cottlehuber wrote: > > > On 22 November 2011 15:08, Dave Cottlehuber wrote: > > > > > > Sorry, seems none of my dropbox links are working this week. > > > > > > Here are the eegg and kriesse versions with links to a couch like I > > > should be doing …. Gist also updated. > > > > > >> Hi devs, > > >> ## references > > > > > > - kriesse [3]: https://github.com/Kriesse/couchdb_web or view at > > > > > > http://skunkwerks.iriscouch.com/couchdocs/_design/couchdocs/kriesse_couch_web/index.html > > > - eegg [4]: https://github.com/eegg/couchdb_web or view at > > > > > > http://skunkwerks.iriscouch.com/couchdocs/_design/couchdocs/eegg_couch_web/index.html > > > > > > A+ > > > Dave > > > > > >
Re: Proposal: Intro to CouchDB Programming class
This sounds like a great idea! On Fri, Nov 25, 2011 at 10:46 PM, Robert Newson wrote: > Happy to help out if time zones line up, excellent project! > > Sent from my iPad > > On 25 Nov 2011, at 22:39, Joan Touzet wrote: > > > Hello CouchDB Developers, > > > > Based on an informal survey of CouchDB users who are interested in > > contributing to the project, two key items tend to hold people back: > > > > 1. Knowing Erlang (and the CouchDB coding style) > > 2. Knowing the CouchDB code base > > > > So I decided to further my own grad research in Education, and > > contribute back to CouchDB, by volunteering to coordinate a class for > > 6-20 students. > > > > ** I'd like to propose an Introduction to CouchDB Programming course, > > kicking off January 5, 2012, and ask for support from the current devs > > on this list. > > > > This won't be a traditional classroom course! Students themselves will > > be shaping the direction of the course, the topics covered, and will be > > expected to lead at least one week of online discussion. (I'll be > > providing the pedagogical framework for this Collaborative Learning > > model. This is my area of active research.) > > > > The idea is that, by the end of course (10 weeks or so), participants > > will have learned enough Erlang to have basic competency, and enough > > about the CouchDB code base to contribute. The "final exam" would be > > completing and submitting some number of patches from the outstanding > > bin of bugs in JIRA. > > > > ** I NEED YOUR HELP in two ways: > > > > A. Suggestions for good reference material (e.g. learnyousomeerlang) > > B. Volunteers from the current devs to conduct a "guided tour" of > > 1 or more parts of the code > > > > The "guided tours" are the essential bits for this class to be > > successful, and I'd like them as much as possible to be accurate and > > accessible to newbs. These tours could take many forms: > > > > * A screencast of you talking about some code, e.g. ScreenFlow > > * A live walkthrough over Adobe Connect video (time donated by my > >University dep't for the class) > > * IRC-based runthrough > > * "Ask the developer" - respond to questions about code on the class > >forum > > * You fly everyone out to your house for dinner :) Etc. > > > > ** If you're willing to help out, please reply on or off list and let me > > know. Let's grow the contributor community! > > > > All the best, > > Joan Touzet (Wohali) > > > > -- > > Joan Touzet | jo...@atypical.net | wohali most other places >
Re: [VOTE] Apache CouchDB new docs proposal
I seem to be missing the start of this thread. What are we voting on? I am happy to lead the way on getting this implemented, and dealing with people's requests, and saying no a lot, and all the other things you have to do when you're trying to avoid designing by committee. But to do that, I'm going to need a designer to help me turn these from mockups into working HTML and CSS for a fully functional site, with each page nicely set out. Copying in kriesse and eegg, on the off chance that either of them have the cycles to devote to this. ;) On Wed, Nov 23, 2011 at 1:23 PM, Robert Newson wrote: > +1 > > On 23 November 2011 10:31, Dave Cottlehuber wrote: > > On 22 November 2011 15:08, Dave Cottlehuber wrote: > > > > Sorry, seems none of my dropbox links are working this week. > > > > Here are the eegg and kriesse versions with links to a couch like I > > should be doing …. Gist also updated. > > > >> Hi devs, > >> ## references > > > > - kriesse [3]: https://github.com/Kriesse/couchdb_web or view at > > > http://skunkwerks.iriscouch.com/couchdocs/_design/couchdocs/kriesse_couch_web/index.html > > - eegg [4]: https://github.com/eegg/couchdb_web or view at > > > http://skunkwerks.iriscouch.com/couchdocs/_design/couchdocs/eegg_couch_web/index.html > > > > A+ > > Dave > > >
Re: python couchdb data collection stops
Could you move this to the user list please? http://couchdb.apache.org/community/lists.html On Mon, Nov 21, 2011 at 6:01 PM, magnetpest2k5 wrote: > Thanks, > > I am not a database guy I dont know much about couchdb either. But from > what > I have found on the web is that each data base can go up to 7.5 GB with > 512000, correct me if I am wrong. With that as threshold the couchdb stops > some time at 0.6gb, some time it goes till 3.8 gb. > > As mentioned in my previous post I use couchdb to store twitter data. I am > sure that the python program does not halt with any exception, the program > keeps running I confirmed this by stopping the storage to couchdb database > and instead storing the output in a CSV format. I found no problem in the > python program. But when I started storing the python dictionary in couchdb > I found that though the program keeps running the storage in couchdb has > stopped. > > I dont know what is happening in log but by just seeing I can find these > lines. I am storing the data on a database called "worldtweets4". Following > are few lines of log where the problem might be as you can see the storage > had stopped I dont get any more 'PUT" /databasename/ID. > > Mon, 21 Nov 2011 14:57:35 GMT] [info] [<0.17870.56>] 127.0.0.1 - - 'PUT' > /worldtweets4/69084bd085994bc7b60ec8f586c69d8f 201 > > [Mon, 21 Nov 2011 15:50:29 GMT] [info] [<0.27616.57>] 127.0.0.1 - - 'GET' > /_all_dbs 200 > > [Mon, 21 Nov 2011 15:50:29 GMT] [info] [<0.23293.57>] 127.0.0.1 - - 'GET' > /_session 200 > > [Mon, 21 Nov 2011 15:50:29 GMT] [info] [<0.27615.57>] 127.0.0.1 - - 'GET' > / > 200 > > [Mon, 21 Nov 2011 15:50:29 GMT] [info] [<0.27617.57>] 127.0.0.1 - - 'GET' > /newdb/ 200 > > [Mon, 21 Nov 2011 15:50:29 GMT] [info] [<0.27617.57>] 127.0.0.1 - - 'GET' > /worldtweets4/ 200 > > [Mon, 21 Nov 2011 15:50:29 GMT] [info] [<0.23293.57>] 127.0.0.1 - - 'GET' > /worldtweets3/ 200 > > [Mon, 21 Nov 2011 15:50:29 GMT] [info] [<0.27616.57>] 127.0.0.1 - - 'GET' > /_users/ 200 > > This same sequence gets repeated and then some where i get the following > > [Mon, 21 Nov 2011 15:59:02 GMT] [info] [<0.28139.57>] 127.0.0.1 - - 'GET' > > /worldtweets4/_all_docs?startkey=%22_design%2F%22&endkey=%22_design0%22&include_docs=true > 200 > > [Mon, 21 Nov 2011 15:59:02 GMT] [info] [<0.28140.57>] 127.0.0.1 - - 'GET' > /_config/query_servers/ 200 > > [Mon, 21 Nov 2011 15:59:02 GMT] [info] [<0.27620.57>] 127.0.0.1 - - 'GET' > /worldtweets4/_all_docs?limit=11&descending=true 200 > > > Do you want me to fill this issue as ticket? in the link you have provided? > > Any help is greatly appreciated > > -- > View this message in context: > http://couchdb-development.1959287.n2.nabble.com/python-couchdb-data-collection-stops-tp7015488p7017272.html > Sent from the CouchDB Development mailing list archive at Nabble.com. >
Re: Proposal: Intro to CouchDB Programming class
Happy to help out if time zones line up, excellent project! Sent from my iPad On 25 Nov 2011, at 22:39, Joan Touzet wrote: > Hello CouchDB Developers, > > Based on an informal survey of CouchDB users who are interested in > contributing to the project, two key items tend to hold people back: > > 1. Knowing Erlang (and the CouchDB coding style) > 2. Knowing the CouchDB code base > > So I decided to further my own grad research in Education, and > contribute back to CouchDB, by volunteering to coordinate a class for > 6-20 students. > > ** I'd like to propose an Introduction to CouchDB Programming course, > kicking off January 5, 2012, and ask for support from the current devs > on this list. > > This won't be a traditional classroom course! Students themselves will > be shaping the direction of the course, the topics covered, and will be > expected to lead at least one week of online discussion. (I'll be > providing the pedagogical framework for this Collaborative Learning > model. This is my area of active research.) > > The idea is that, by the end of course (10 weeks or so), participants > will have learned enough Erlang to have basic competency, and enough > about the CouchDB code base to contribute. The "final exam" would be > completing and submitting some number of patches from the outstanding > bin of bugs in JIRA. > > ** I NEED YOUR HELP in two ways: > > A. Suggestions for good reference material (e.g. learnyousomeerlang) > B. Volunteers from the current devs to conduct a "guided tour" of > 1 or more parts of the code > > The "guided tours" are the essential bits for this class to be > successful, and I'd like them as much as possible to be accurate and > accessible to newbs. These tours could take many forms: > > * A screencast of you talking about some code, e.g. ScreenFlow > * A live walkthrough over Adobe Connect video (time donated by my >University dep't for the class) > * IRC-based runthrough > * "Ask the developer" - respond to questions about code on the class >forum > * You fly everyone out to your house for dinner :) Etc. > > ** If you're willing to help out, please reply on or off list and let me > know. Let's grow the contributor community! > > All the best, > Joan Touzet (Wohali) > > -- > Joan Touzet | jo...@atypical.net | wohali most other places
Proposal: Intro to CouchDB Programming class
Hello CouchDB Developers, Based on an informal survey of CouchDB users who are interested in contributing to the project, two key items tend to hold people back: 1. Knowing Erlang (and the CouchDB coding style) 2. Knowing the CouchDB code base So I decided to further my own grad research in Education, and contribute back to CouchDB, by volunteering to coordinate a class for 6-20 students. ** I'd like to propose an Introduction to CouchDB Programming course, kicking off January 5, 2012, and ask for support from the current devs on this list. This won't be a traditional classroom course! Students themselves will be shaping the direction of the course, the topics covered, and will be expected to lead at least one week of online discussion. (I'll be providing the pedagogical framework for this Collaborative Learning model. This is my area of active research.) The idea is that, by the end of course (10 weeks or so), participants will have learned enough Erlang to have basic competency, and enough about the CouchDB code base to contribute. The "final exam" would be completing and submitting some number of patches from the outstanding bin of bugs in JIRA. ** I NEED YOUR HELP in two ways: A. Suggestions for good reference material (e.g. learnyousomeerlang) B. Volunteers from the current devs to conduct a "guided tour" of 1 or more parts of the code The "guided tours" are the essential bits for this class to be successful, and I'd like them as much as possible to be accurate and accessible to newbs. These tours could take many forms: * A screencast of you talking about some code, e.g. ScreenFlow * A live walkthrough over Adobe Connect video (time donated by my University dep't for the class) * IRC-based runthrough * "Ask the developer" - respond to questions about code on the class forum * You fly everyone out to your house for dinner :) Etc. ** If you're willing to help out, please reply on or off list and let me know. Let's grow the contributor community! All the best, Joan Touzet (Wohali) -- Joan Touzet | jo...@atypical.net | wohali most other places
Re: Git process description from an ASF project
>> [GitHib is not necessary to get the most from Git] IMHO, a gitweb >> instance would be good enough for Deltacloud; a gitorious >> instance of course much shinier. Whatever infra feels is the best tool >> from their side would be fine by me. >> >> [Is a plain vanilla Git repo enough? What do we *need*? What would add >> additional value?] > > A plain Git repo is definitely a good start but the ability to browse > via a browser is super handy! (Gitorious or Gitolite accommodate that > use case.) GitHub's faculties for forking, reviewing, commenting are > also super useful but not mandatory. Just better ergonomics. Not to mention the additional value of github pages, integrated issue tracking (with, for example, the ability to close issues via commits), as well as the integrated wiki. Those things are technically not needed but are becoming increasingly important for developers in the Callback community (and increasingly the open source community at large) for whom those features are becoming indispensable. Thanks for adding this to the discussion Ross!
[jira] [Assigned] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana reassigned COUCHDB-1320: -- Assignee: Benoit Chesneau (was: Filipe Manana) Benoit, assigning this to you for review. thanks > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham >Assignee: Benoit Chesneau > Attachments: Fix-OAuth-that-broke-with-vhost.patch, > fdmanana-0001-Fix-OAuth-authentication-with-VHosts-URL-rewriting.patch > > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1320: --- Attachment: fdmanana-0001-Fix-OAuth-authentication-with-VHosts-URL-rewriting.patch Martin, I've spent some time testing this well. The patch you provided didn't seem to fix it. I added some tests to confirm the fix, which uses VHosts + URL rewriting. A big part of the problem here is that the OAuth handler is executed 2 times: 1) after the VHost dispatch happens and before the rewriter is called; 2) after the rewriter is called. This time the OAuth handler gets a rewritten patch which will cause the OAuth signature check to fail, since the client's provided signature is based on the first path (pre VHost dispatch, and pre rewriting phase) The patch I'm attaching here explains this in the commit message. Also, leaving it for Benoît to confirm if this is an ok fix. > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham >Assignee: Filipe Manana > Attachments: Fix-OAuth-that-broke-with-vhost.patch, > fdmanana-0001-Fix-OAuth-authentication-with-VHosts-URL-rewriting.patch > > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Git process description from an ASF project
This is useful, I will aggregate to the wiki, but first, have some comments/questions inline below: > [Most ASF projects operate on RTC for non-committers and CTR for > committers - is this likely to change with Git? Should it change? If > it need not change how do we ensure frequent pushed from committers?] RTC (review then commit) is how we currently operate. I would like us to continue operating in this fashion. The test here, is that we use the wonderfully user friendly GitHub pull request mechanism to do the reviewing part. The committing part to the canonical ASF repo would be done once a review is deemed successful (CLA in place, IP clear). Is this going to be acceptable? > [The issue of SVN losing Author and Committer roles will disappear > with a Git central repo. What is the optimal process for handling > non-committer patches then?] I think the process outlined above works nicely. Note, the GitHub part isn't a requirement (obviously) but rather just another channel. Email patches work too but are, of course, more work and, frankly, unlikely from our audience. > [People mostly share changes] on the mailing list, sending patches > around (for those who > haven't used git a lot: git makes it very easy to work with patch series > from others, in parallel to your own ongoing work) I personally find > github's model of sending merge requests and merging in other repos less > productive, in particular since I am very strict about maintaining a > linear master branch (git-svn forces that, but even for my non-ASF > projects do I insist on that, since it makes things like bisecting a ton > easier) > > [Do you agree with these observations about GitHub merge requests? No. > Are we likely to find this model the norm. for people using GitHub? Do > other Git hosting environments encourage this workflow? What is the > optimal process for an ASF project?] My thoughts are that we treat a patch, regardless of origin, the same. It has be cleared of IP concern and merged to the canonical repo hosted by the ASF by a committer. > On occasion, I've uploaded a patch series to my people.apache.org page, > usually when the patches are huge and there is danger that they get > mangled in email. > > [Does the ASF need some facility for this?] This is an interesting question. I pinged the GitHub guys to see about their enterprise package. I think we could arrange getting it subsidized and/or donated to the ASF. Regardless, not a big infra q. > In other projects, I've merged patches directly from other people's > repos, but as I said, I find that more annoying than applying a series > of patches directly. Guess this is a personal pref, I prefer the oposite! > Whether you see a lot of public branches in a git project depends a lot > on how the project takes in contributions: via merge from other git > repos, or through patches posted to a mailing list. But even when > contributions come through merging of other git repos, you rarely see > branches in the canonical git repo. I don't think the origin of a patch has much to do w/ the local developer workflow and the larger project workflows. We branch heavily on a project basis for longer lived features and, most of us, do local topic branches per feature/bug. Its a strength of Git to branch cheaply, so we do. > [There's that same alternative process again? Any more comments in > this context? Should ASF projects be encouraged to follow one process > and not the other? Should it be left to individual projects?] I think there are some good practices we could encourage but certainly do not think we'd want to enforce a particular flow. Projects with a few contributors don't need to go crazy w/ branching but ones like PhoneGap couldn't live without it. > [How git affects the community] highly depends who the community > members are: if they have a strong > git background, they'll be unhappy with svn; if they have a strong svn > background, they'll be unhappy with git. And not just the tools, but > also the differing workflows these tools accomodate. Thats interesting b/c, and this is my personal case, most developers using Git have extensive experience w/ SVN. I tend to find that the oposite is not true. Anyhow, not relevant to the ASF from my perspective. The ASF is about the community over the code and in that spirit support for Git is emerging satisfying both dev communities. > [If a project moves to Git how to we minimise the pain for SVN users? > If a project stays with SVN are the Git mirrors we currently have the > best we can do for Git users? Can projects that stay on SVN benefit > from lessons learned in the GIt projects?] Pretty great question. I'm of the opinion that shuffling code between RCS systems creates more problems than it solves. A developer should have acumen in both technologies these days. Should a project accommodating a developer whom refuses to pick up the RCS chosen by a project? I don't think so. > [GitHib is not necess
[jira] [Updated] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Dionne updated COUCHDB-1289: Attachment: 0002-Failing-etap-for-heartbeats-skipped.patch 0001-Ensure-heartbeats-are-not-skipped.patch second draft of patch. Filipe, this handles both cases now and is refactored to be a bit simpler. > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > Attachments: 0001-Ensure-heartbeats-are-not-skipped.patch, > 0002-Failing-etap-for-heartbeats-skipped.patch > > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Dionne updated COUCHDB-1289: Attachment: (was: 0001-Ensure-heartbeats-are-not-skipped-in-continuous-chan.patch) > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1347) Filtered replication does not work when a target document is purged
Filtered replication does not work when a target document is purged
---
Key: COUCHDB-1347
URL: https://issues.apache.org/jira/browse/COUCHDB-1347
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1, 1.0.1
Environment: OS X Lion: {"couchdb":"Welcome","version":"1.1.0"} (brew
installation)
Ubuntu 11.04 {"couchdb":"Welcome","version":"1.0.1"}
Reporter: Benjamin ter Kuile
When a document with an id is deleted and purged, and a replication process
tries to create a document with that id, it does not happen. The replication
without the filter works. Ruby test script:
require 'rubygems'
require 'couchrest'
# setup
server = CouchRest.new("http://localhost:5984";)
a = server.database('a')
b = server.database('b')
a.recreate!
b.recreate!
# Add a document doc1 to database a and b
a.save_doc("_id" => 'doc1')
b_doc1 = b.save_doc("_id" => 'doc1')
# Delete and purge doc1 from b
b.delete_doc("_id" => 'doc1', "_rev" => b_doc1['rev'])
RestClient.post(File.join(b.root, '_purge'), {'doc1' =>
[b_doc1['rev']]}.to_json, :content_type => :json )
# Add design with filter
design = a.save_doc("_id" => "_design/temp", "filters" => {"test" =>
%|function(doc, req){if(['doc1'].indexOf(doc['_id']) >= 0){return true;}{return
false;}}|})
# Replicate and wait for finish
RestClient.post("http://localhost:5984/_replicate";, {:source => a.root, :filter
=> "temp/test", :target => b.root}.to_json, :content_type => :json)
sleep(0.01) while
JSON.parse(RestClient.get("http://localhost:5984/_active_tasks";)).size > 0
abort "oops" unless b.all_docs['total_rows'] == 1
puts "Test successful"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157137#comment-13157137 ] Filipe Manana commented on COUCHDB-1320: Thanks Martin. I'll give it a try soon. > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham >Assignee: Filipe Manana > Attachments: Fix-OAuth-that-broke-with-vhost.patch > > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana reassigned COUCHDB-1320: -- Assignee: Filipe Manana > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham >Assignee: Filipe Manana > Attachments: Fix-OAuth-that-broke-with-vhost.patch > > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157134#comment-13157134 ] Martin Higham commented on COUCHDB-1320: Attached fix. > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham > Attachments: Fix-OAuth-that-broke-with-vhost.patch > > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Higham updated COUCHDB-1320: --- Attachment: Fix-OAuth-that-broke-with-vhost.patch > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham > Attachments: Fix-OAuth-that-broke-with-vhost.patch > > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1320) OAuth authentication doesn't work with VHost entry
[ https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157125#comment-13157125 ] Martin Higham commented on COUCHDB-1320: COUCHDB-1321 doesn't fix this because it copies the value of raw_path which is wrong when a vhost is set. If the header x-couchdb-vhost-path is set then that value should be used instead > OAuth authentication doesn't work with VHost entry > -- > > Key: COUCHDB-1320 > URL: https://issues.apache.org/jira/browse/COUCHDB-1320 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 1.1 > Environment: Ubuntu >Reporter: Martin Higham > > If you have a vhost entry that modifies the path (such as my host.com = > /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host > using OAuth fails. > couch_httpd_oauth uses the modified path rather than the original > x-couchdb-vhost-path when calculating the signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Git process description from an ASF project
Below are a set of comments and process descriptions adopted by Deltacloud in relation to Git. This comes from a private discussion and I only have permission to repeat the words of David Luttekort (other posters did not withhold permission, but they've not granted it explicitly, so I'm being cautious, as a result I've edited Davids words occasionally so they make sense where I've cut a previous comment). I wonder if this content would be useful for the wiki or for driving discussion about whether these are optimal approaches. I'm not a git user (at least not in a project with more than two committers) so I don't feel qualified to comment directly. David says (I've injected a few comments/questions in [square brackets]): I'll share some of the experiences that Deltacloud had; since the project started on git, and switched to svn only because of entering the ASF incubator, the project's workflows and conventions are about as close as you can get to a git-only project while using git-svn. [Push rates vary.] The workflow that Deltacloud (and a lot of git-centric projects) use is review-before-commit, i.e. you post your proposed patches on the mailing list, and should only commit them to the central repo (now done via 'git svn dcommit') once at least one other person has reviewed and ACK'd them. [Most ASF projects operate on RTC for non-committers and CTR for committers - is this likely to change with Git? Should it change? If it need not change how do we ensure frequent pushed from committers?] Patches from non-committers are committed by a committer on the non-committer's behalf. Unfortunately, svn does not preserve the separate Author and Committer roles that git does; we've therefore switched to using 'Signed-off-by' to make sure we record the original author of a patch. Of course, committers are responsible for checking that patches they commit for others are backed by a CLA etc. [The issue of SVN losing Author and Committer roles will disappear with a Git central repo. What is the optimal process for handling non-committer patches then?] [People mostly share changes] on the mailing list, sending patches around (for those who haven't used git a lot: git makes it very easy to work with patch series from others, in parallel to your own ongoing work) I personally find github's model of sending merge requests and merging in other repos less productive, in particular since I am very strict about maintaining a linear master branch (git-svn forces that, but even for my non-ASF projects do I insist on that, since it makes things like bisecting a ton easier) [Do you agree with these observations about GitHub merge requests? Are we likely to find this model the norm. for people using GitHub? Do other Git hosting environments encourage this workflow? What is the optimal process for an ASF project?] On occasion, I've uploaded a patch series to my people.apache.org page, usually when the patches are huge and there is danger that they get mangled in email. [Does the ASF need some facility for this?] In other projects, I've merged patches directly from other people's repos, but as I said, I find that more annoying than applying a series of patches directly. > Branches in the ASF repository, or are people hosting them elsewhere? For Deltacloud, we do not have any public branches. I think there were one or two occasions in the pre-incubator days where we had a public branch because we did a fundamental overhaul of the codebase and didn't want to disturb the ongoing work on the master branch. Whether you see a lot of public branches in a git project depends a lot on how the project takes in contributions: via merge from other git repos, or through patches posted to a mailing list. But even when contributions come through merging of other git repos, you rarely see branches in the canonical git repo. There, you'd expect to see branches for exactly the same reasons you'd see them in svn: to support longer-lived work that deviates from master. [There's that same alternative process again? Any more comments in this context? Should ASF projects be encouraged to follow one process and not the other? Should it be left to individual projects?] [How git affects the community] highly depends who the community members are: if they have a strong git background, they'll be unhappy with svn; if they have a strong svn background, they'll be unhappy with git. And not just the tools, but also the differing workflows these tools accomodate. [If a project moves to Git how to we minimise the pain for SVN users? If a project stays with SVN are the Git mirrors we currently have the best we can do for Git users? Can projects that stay on SVN benefit from lessons learned in the GIt projects?] [GitHib is not necessary to get the most from Git] IMHO, a gitweb instance would be good enough for Deltacloud; a gitorious instance of course much shinier. Whatever infra feels is the best tool from their side would be fine by me. [Is
