[jira] Created: (COUCHDB-611) Double-escaping of ampersands when editing in Futon
Double-escaping of ampersands when editing in Futon --- Key: COUCHDB-611 URL: https://issues.apache.org/jira/browse/COUCHDB-611 Project: CouchDB Issue Type: Bug Components: Futon Environment: Safari 4.0.4 or Firefox 3.6b5 Reporter: Jason Davies To reproduce, create a new document in Futon and add a test field with the value []. Click the green tick button to apply and then edit the value again, and now it will show [amp;]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COUCHDB-598) _show without docid returns 500 instead of 404
[
https://issues.apache.org/jira/browse/COUCHDB-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies resolved COUCHDB-598.
--
Resolution: Won't Fix
_show without docid returns 500 instead of 404
--
Key: COUCHDB-598
URL: https://issues.apache.org/jira/browse/COUCHDB-598
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.10
Environment: Ubuntu Karmic
Reporter: Markus
Priority: Minor
See also the thread on the mailing
list::http://www.mail-archive.com/u...@couchdb.apache.org/msg05633.html and
especially the following quote from Chris Anderson : The change would be
simple, just remove a catch clause on couch_httpd_show.erl line 81.
Original message below:
--
According to
http://books.couchdb.org/relax/design-documents/shows#Querying%20Show%
20Functions i should receive an HTTP 404 Not Found response, instead i
get a HTTP 500 Internal Server Error. I am unsure as of yet whether i am
doing something wrong or if i should file a bug report for this one.
Here are my two documents in my test database named shows:
{
_id: _design/test,
_rev: 1-21a6d69070ae4bec3e9f14fbb7f93201,
shows: {
summary: function (doc, req) { return
'h1'+doc.title+'/h1p'+doc.body+'/p'; }
}
}
and
{
_id: bd108c433aedaa1bd2def0ec85e59a0d,
_rev: 3-5a031adf97aabe4888b9bfb94ba28d13,
title: title,
body: body text
}
I receive proper results using the following HTTP GET request
http://zealand:5984/shows/_design/test/_show/summary/bd108c433aedaa1bd2def0ec85e59a0d
- code : 200
- body : h1title/h1pbody text/p
Now consider querying the same show function with a non-existing
document id
http://zealand:5984/shows/_design/test/_show/summary/404
- code 500
- body {error:normal,reason:{gen_server,call,\n
[couch_query_servers,\n {ret_proc,{proc,0.1481.0,
\javascript\,\n
{couch_os_process,prompt},\n
{couch_os_process,set_timeout},\n
{couch_os_process,stop}}}]}}
Here is the output in the couch.log file:
[Tue, 01 Dec 2009 10:31:37 GMT] [debug] [0.1594.0] OAuth Params: []
[Tue, 01 Dec 2009 10:31:37 GMT] [info] [0.1726.0] OS Process ::
function raised error: TypeError: doc is null
[Tue, 01 Dec 2009 10:31:37 GMT] [info] [0.1726.0] OS Process ::
stacktrace: (null,[object Object])@:0
runShow(function (doc, req) {return h1 + doc.title + /h1p +
doc.body + /p;},null,[object Object],function (doc, req) { return
'h1'+doc.title+'/h1p'+doc.body+'/p'; }
)@/usr/share/couchdb/server/main.js:388
(function (doc, req) { return 'h1'+doc.title+'/h1p'+doc.body
+'/p'; } ,null,[object Object])@/usr/share/couchdb/server/main.js:358
@/usr/share/couchdb/server/main.js:842
[Tue, 01 Dec 2009 10:31:37 GMT] [error] [0.1594.0] OS Process Error ::
{render_error,{[{body,
htmlbodyh1Render
Error/h1pJavaScript function raised error: TypeError: doc is
null/ph2Stacktrace:/h2codepre(null,[object Object])@:0
\nrunShow(function (doc, req) {return \lt;h1gt;\ + doc.title +
\lt;/h1gt;lt;pgt;\ + doc.body + \lt;/pgt;\;},null,[object
Object],\function (doc, req) { return 'lt;h1gt;'+doc.title
+'lt;/h1gt;lt;pgt;'+doc.body+'lt;/pgt;'; }
\)@/usr/share/couchdb/server/main.js:388\n(\function (doc, req)
{ return 'lt;h1gt;'+doc.title+'lt;/h1gt;lt;pgt;'+doc.body
+'lt;/pgt;'; } \,null,[object
Object])@/usr/share/couchdb/server/main.js:358
\n@/usr/share/couchdb/server/main.js:842\n/pre/codeh2Function
source:/h2codeprefunction (doc, req) { return
'lt;h1gt;'+doc.title+'lt;/h1gt;lt;pgt;'+doc.body+'lt;/pgt;'; }
/pre/code/body/html}]}}
[Tue, 01 Dec 2009 10:31:37 GMT] [debug] [0.1628.0] Unknown linked
process died: 0.1726.0 (reason: normal)
[Tue, 01 Dec 2009 10:31:37 GMT] [error] [0.53.0]
{error_report,0.24.0,
{0.53.0,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,child_terminated},
{reason,normal},
{offender,[{pid,0.1628.0},
{name,query_servers},
{mfa,{couch_query_servers,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
[Tue, 01 Dec 2009 10:31:37 GMT] [error] [0.1594.0] Uncaught error in
HTTP request: {exit,
{normal,
{gen_server,call,
[couch_query_servers,
{ret_proc,
{proc,0.1726.0,javascript,
{couch_os_process,prompt},
{couch_os_process,set_timeout},
[jira] Commented: (COUCHDB-598) _show without docid returns 500 instead of 404
[
https://issues.apache.org/jira/browse/COUCHDB-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790250#action_12790250
]
Jason Davies commented on COUCHDB-598:
--
I think this is the expected behaviour, and the example in the book is probably
at fault.
We used to return a 404 when the document didn't exist, but we needed the
ability to define a custom response for non-existent docs e.g. a custom 404
page, or a 302 redirect, so now we pass null to the show function instead. As
your show function doesn't handle the case when doc === null, it is raising an
exception and causing a 500 error. Your code should test for doc === null and
return {code: 404, ...} to avoid the 500 error.
I propose marking this as wontfix, any objections?
_show without docid returns 500 instead of 404
--
Key: COUCHDB-598
URL: https://issues.apache.org/jira/browse/COUCHDB-598
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.10
Environment: Ubuntu Karmic
Reporter: Markus
Priority: Minor
See also the thread on the mailing
list::http://www.mail-archive.com/u...@couchdb.apache.org/msg05633.html and
especially the following quote from Chris Anderson : The change would be
simple, just remove a catch clause on couch_httpd_show.erl line 81.
Original message below:
--
According to
http://books.couchdb.org/relax/design-documents/shows#Querying%20Show%
20Functions i should receive an HTTP 404 Not Found response, instead i
get a HTTP 500 Internal Server Error. I am unsure as of yet whether i am
doing something wrong or if i should file a bug report for this one.
Here are my two documents in my test database named shows:
{
_id: _design/test,
_rev: 1-21a6d69070ae4bec3e9f14fbb7f93201,
shows: {
summary: function (doc, req) { return
'h1'+doc.title+'/h1p'+doc.body+'/p'; }
}
}
and
{
_id: bd108c433aedaa1bd2def0ec85e59a0d,
_rev: 3-5a031adf97aabe4888b9bfb94ba28d13,
title: title,
body: body text
}
I receive proper results using the following HTTP GET request
http://zealand:5984/shows/_design/test/_show/summary/bd108c433aedaa1bd2def0ec85e59a0d
- code : 200
- body : h1title/h1pbody text/p
Now consider querying the same show function with a non-existing
document id
http://zealand:5984/shows/_design/test/_show/summary/404
- code 500
- body {error:normal,reason:{gen_server,call,\n
[couch_query_servers,\n {ret_proc,{proc,0.1481.0,
\javascript\,\n
{couch_os_process,prompt},\n
{couch_os_process,set_timeout},\n
{couch_os_process,stop}}}]}}
Here is the output in the couch.log file:
[Tue, 01 Dec 2009 10:31:37 GMT] [debug] [0.1594.0] OAuth Params: []
[Tue, 01 Dec 2009 10:31:37 GMT] [info] [0.1726.0] OS Process ::
function raised error: TypeError: doc is null
[Tue, 01 Dec 2009 10:31:37 GMT] [info] [0.1726.0] OS Process ::
stacktrace: (null,[object Object])@:0
runShow(function (doc, req) {return h1 + doc.title + /h1p +
doc.body + /p;},null,[object Object],function (doc, req) { return
'h1'+doc.title+'/h1p'+doc.body+'/p'; }
)@/usr/share/couchdb/server/main.js:388
(function (doc, req) { return 'h1'+doc.title+'/h1p'+doc.body
+'/p'; } ,null,[object Object])@/usr/share/couchdb/server/main.js:358
@/usr/share/couchdb/server/main.js:842
[Tue, 01 Dec 2009 10:31:37 GMT] [error] [0.1594.0] OS Process Error ::
{render_error,{[{body,
htmlbodyh1Render
Error/h1pJavaScript function raised error: TypeError: doc is
null/ph2Stacktrace:/h2codepre(null,[object Object])@:0
\nrunShow(function (doc, req) {return \lt;h1gt;\ + doc.title +
\lt;/h1gt;lt;pgt;\ + doc.body + \lt;/pgt;\;},null,[object
Object],\function (doc, req) { return 'lt;h1gt;'+doc.title
+'lt;/h1gt;lt;pgt;'+doc.body+'lt;/pgt;'; }
\)@/usr/share/couchdb/server/main.js:388\n(\function (doc, req)
{ return 'lt;h1gt;'+doc.title+'lt;/h1gt;lt;pgt;'+doc.body
+'lt;/pgt;'; } \,null,[object
Object])@/usr/share/couchdb/server/main.js:358
\n@/usr/share/couchdb/server/main.js:842\n/pre/codeh2Function
source:/h2codeprefunction (doc, req) { return
'lt;h1gt;'+doc.title+'lt;/h1gt;lt;pgt;'+doc.body+'lt;/pgt;'; }
/pre/code/body/html}]}}
[Tue, 01 Dec 2009 10:31:37 GMT] [debug] [0.1628.0] Unknown linked
process died: 0.1726.0 (reason: normal)
[Tue, 01 Dec 2009 10:31:37 GMT] [error] [0.53.0]
{error_report,0.24.0,
{0.53.0,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,child_terminated},
{reason,normal},
{offender,[{pid,0.1628.0},
{name,query_servers},
{mfa,{couch_query_servers,start_link,[]}},
{restart_type,permanent},
[jira] Commented: (COUCHDB-525) create_target replication option should work with OAuth
[ https://issues.apache.org/jira/browse/COUCHDB-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765279#action_12765279 ] Jason Davies commented on COUCHDB-525: -- Fixed in r824954. Leaving this open for now as I need to add a test for this. create_target replication option should work with OAuth --- Key: COUCHDB-525 URL: https://issues.apache.org/jira/browse/COUCHDB-525 Project: CouchDB Issue Type: Bug Affects Versions: 0.11 Reporter: Adam Kocoloski Assignee: Jan Lehnardt Priority: Minor Attachments: COUCHDB-525.patch The new create_target option makes an HTTP request with an OAuth signature that assumes HEAD rather than PUT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COUCHDB-525) create_target replication option should work with OAuth
[ https://issues.apache.org/jira/browse/COUCHDB-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies reassigned COUCHDB-525: Assignee: Jason Davies (was: Jan Lehnardt) create_target replication option should work with OAuth --- Key: COUCHDB-525 URL: https://issues.apache.org/jira/browse/COUCHDB-525 Project: CouchDB Issue Type: Bug Affects Versions: 0.11 Reporter: Adam Kocoloski Assignee: Jason Davies Priority: Minor Attachments: COUCHDB-525.patch The new create_target option makes an HTTP request with an OAuth signature that assumes HEAD rather than PUT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-522) supplying a bad TokenSecret causes a 500 error response
[
https://issues.apache.org/jira/browse/COUCHDB-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies closed COUCHDB-522.
Resolution: Fixed
Fixed in r824290.
supplying a bad TokenSecret causes a 500 error response
---
Key: COUCHDB-522
URL: https://issues.apache.org/jira/browse/COUCHDB-522
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.10
Reporter: Adam Kocoloski
Assignee: Jason Davies
It seems that if a user tries to authenticate with OAuth using a token secret
that CouchDB doesn't know about, the result will be an Internal Server Error
and a traceback that looks like
[Thu, 08 Oct 2009 14:44:19 GMT] [info] [0.1103.24] Stacktrace:
[{oauth_uri,encode,[undefined,[]]},
{oauth_uri,'-calate/2-lc$^0/1-0-',1},
{oauth_uri,'-calate/2-lc$^0/1-0-',1},
{oauth_uri,calate,2},
{oauth_hmac_sha1,signature,3},
{oauth_hmac_sha1,verify,4},
{couch_httpd_oauth,'-oauth_authentication_handler/1-fun-0-',6},
{couch_httpd,authenticate_request,2}]
I think we could fix this by replacing
TokenSecret = couch_config:get(oauth_token_secrets, AccessToken),
with
TokenSecret = couch_config:get(oauth_token_secrets, AccessToken, ),
or some other more appropriate default string.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-525) create_target replication option should work with OAuth
[ https://issues.apache.org/jira/browse/COUCHDB-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-525: - Attachment: COUCHDB-525.patch Jan: I think that would result in an invalid signature for the second (HEAD) request. This patch covers both the HEAD and PUT requests. Yes, a test would be nice :-) create_target replication option should work with OAuth --- Key: COUCHDB-525 URL: https://issues.apache.org/jira/browse/COUCHDB-525 Project: CouchDB Issue Type: Bug Affects Versions: 0.11 Reporter: Adam Kocoloski Assignee: Jan Lehnardt Priority: Minor Attachments: COUCHDB-525.patch The new create_target option makes an HTTP request with an OAuth signature that assumes HEAD rather than PUT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COUCHDB-438) Add per database (OAuth) authentication to couchdb
[ https://issues.apache.org/jira/browse/COUCHDB-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies reassigned COUCHDB-438: Assignee: Jason Davies Add per database (OAuth) authentication to couchdb -- Key: COUCHDB-438 URL: https://issues.apache.org/jira/browse/COUCHDB-438 Project: CouchDB Issue Type: New Feature Affects Versions: 0.10 Reporter: eric casteleijn Assignee: Jason Davies Priority: Blocker Fix For: 0.11 In set-ups where a couchdb node holds databases for many different users that are not allowed to see each other's data, it is vital that it is possible to give users separate roles for each database. It would be best if adding new users, and assigning roles to users for specific databases could be done through the http interface, as modifying .ini files becomes unwieldy for large numbers of users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies reassigned COUCHDB-512: Assignee: Jason Davies Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Components: Database Core Reporter: Jason Davies Assignee: Jason Davies Fix For: 0.10 Attachments: per_db_auth.1.patch, per_db_auth.patch Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-513) Unable to redirect from _list function
[
https://issues.apache.org/jira/browse/COUCHDB-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies closed COUCHDB-513.
Resolution: Invalid
To send headers you need to use the start() function for _list, e.g.
function(head, req) {
start({code:301, headers: { 'Location': 'http://www.google.com/' }});
}
Unable to redirect from _list function
--
Key: COUCHDB-513
URL: https://issues.apache.org/jira/browse/COUCHDB-513
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 0.11
Environment: Mac OS X 10.5.8, Erlang OTP/R12B, CouchDB/0.11.0a9fd42dc1
Reporter: Zachary Zolton
Priority: Minor
Define this _list function:
function(head, req) {
return {
'code': 301,
'headers': { 'Location': 'http://www.google.com/' }
};
}
Try to curl it:
$ curl -i
'http://localhost:5984/db/_design/ddoc/_list/test-redirect/some-view?key=%22foo%22'
HTTP/1.1 200 OK
Vary: Accept
Transfer-Encoding: chunked
Server: CouchDB/0.11.0a9fd42dc1-git (Erlang OTP/R12B)
Etag: 46014W5JDRLKZF5SECP2D44YH
Date: Thu, 24 Sep 2009 22:23:14 GMT
Content-Type: application/json
curl: (56) Received problem 2 in the chunky parser
Here is Jan's take on the user mailing list:
http://mail-archives.apache.org/mod_mbox/couchdb-user/200909.mbox/%3c6678e46d-a113-4052-9f44-e061582d2...@apache.org%3e
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12759096#action_12759096 ] Jason Davies commented on COUCHDB-512: -- Hi Adam, it seems I was mistakenly under the impression firewall rules work in the last match fashion, I think I will update the patch, thanks :-) Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Components: Database Core Reporter: Jason Davies Fix For: 0.10 Attachments: per_db_auth.patch Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12759099#action_12759099 ] Jason Davies commented on COUCHDB-512: -- Benoit, I think we will definitely add per-db ACLs in the future, it shouldn't be hard to do. As for replicating ACLs I think that should probably be off by default as it could cause complications, but it would be needed for a cluster configuration so we would need to support it at some point. Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Components: Database Core Reporter: Jason Davies Fix For: 0.10 Attachments: per_db_auth.patch Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-512: - Attachment: per_db_auth.1.patch Fix for error when ACL doc is missing. Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Components: Database Core Reporter: Jason Davies Fix For: 0.10 Attachments: per_db_auth.1.patch, per_db_auth.patch Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-512) Per-DB Authorization and ACL
Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Reporter: Jason Davies Fix For: 0.10 Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-512: - Component/s: Database Core Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Components: Database Core Reporter: Jason Davies Fix For: 0.10 Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-512) Per-DB Authorization and ACL
[
https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-512:
-
Attachment: per_db_auth.patch
Initial patch adding per-db auth using an ACL rule list defined in the
_local/_acl in the users db (users by default). We can look at extending
this and allow a similar document to exist per database too in the future. The
ACL document looks like:
{
_id: _local/_acl,
rules: [
{db: *, role: *, deny: *},
{db: *, role: test, allow: read},
]
}
The last matching rule wins.
Per-DB Authorization and ACL
Key: COUCHDB-512
URL: https://issues.apache.org/jira/browse/COUCHDB-512
Project: CouchDB
Issue Type: New Feature
Components: Database Core
Reporter: Jason Davies
Fix For: 0.10
Attachments: per_db_auth.patch
Following discussions on the mailing list, this is for tracking work and
comments surrounding an implementation of per-db authorization and ACL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-470) Include peer in req object for lists, shows and updates
[ https://issues.apache.org/jira/browse/COUCHDB-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies closed COUCHDB-470. Resolution: Fixed Fixed in r818316. Include peer in req object for lists, shows and updates --- Key: COUCHDB-470 URL: https://issues.apache.org/jira/browse/COUCHDB-470 Project: CouchDB Issue Type: Improvement Reporter: Jason Davies Attachments: couch_httpd_external.peer.patch Simple one-liner. Useful for statistical tracking or any kind of IP-based switching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-432) Upgrade Futon's json2.js and jquery.js
[ https://issues.apache.org/jira/browse/COUCHDB-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755457#action_12755457 ] Jason Davies commented on COUCHDB-432: -- Any objections to me committing this? Mr. Lenz? All tests pass for me (although I'm getting unrelated spurious failures probably due to the stats collector). Upgrade Futon's json2.js and jquery.js -- Key: COUCHDB-432 URL: https://issues.apache.org/jira/browse/COUCHDB-432 Project: CouchDB Issue Type: Improvement Affects Versions: 0.10 Reporter: Devin Torres Priority: Minor Fix For: 0.10 Original Estimate: 0.02h Remaining Estimate: 0.02h The json2.js file currently being used by Futon is over a year old and contains bugs and security issues. I've updated it to the most recent version on json.org http://www.json.org/json2.js and all the tests pass on FF3.0 and FF3.5. Also, you can upgrae jquery to 1.3.2. All tests also pass with this upgrade. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-448) Support Gzip encoding for replicating over slow connections
[ https://issues.apache.org/jira/browse/COUCHDB-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755747#action_12755747 ] Jason Davies commented on COUCHDB-448: -- Note to self or whoever implements this: the ETag should change depending on what Content-Encoding is used. Support Gzip encoding for replicating over slow connections --- Key: COUCHDB-448 URL: https://issues.apache.org/jira/browse/COUCHDB-448 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Jason Davies Assignee: Adam Kocoloski This shouldn't be too hard to add, we should support it in general for all HTTP requests to the server and also allow it to be enabled in the replicator client for pull/push replication. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-502) Large objects/text crash Futon
[ https://issues.apache.org/jira/browse/COUCHDB-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-502: - Component/s: (was: JavaScript View Server) Administration Console Summary: Large objects/text crash Futon (was: Large objects/text crash the view server) Verified in Futon on trunk. Large JSON strings cause Futon to be very slow, not CouchDB itself. Large objects/text crash Futon -- Key: COUCHDB-502 URL: https://issues.apache.org/jira/browse/COUCHDB-502 Project: CouchDB Issue Type: Bug Components: Administration Console Affects Versions: 0.9.1 Environment: Futon on Apache CouchDB 0.9.1, ubuntu Reporter: Jos Boumans Attachments: test.json Any sufficiently large JSON object will cause script time outs in firefox/safari. The example object I used had 500 individual keys, whose values were hashes with 20 individual keys. Storing that same JSON ***AS STRING*** made firefox issue the following error on the console, stopping rendering altogether: script stack space quota is exhausted. Statement executed is: var match = quickExpr.exec( selector );\n from jquery.js?1.3.1 (line 50) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-502) Large objects/text crash Futon
[ https://issues.apache.org/jira/browse/COUCHDB-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-502: - Attachment: test.json Test JSON data. To reproduce, copy and paste its contents into a field in a document in Futon. Large objects/text crash Futon -- Key: COUCHDB-502 URL: https://issues.apache.org/jira/browse/COUCHDB-502 Project: CouchDB Issue Type: Bug Components: Administration Console Affects Versions: 0.9.1 Environment: Futon on Apache CouchDB 0.9.1, ubuntu Reporter: Jos Boumans Attachments: test.json Any sufficiently large JSON object will cause script time outs in firefox/safari. The example object I used had 500 individual keys, whose values were hashes with 20 individual keys. Storing that same JSON ***AS STRING*** made firefox issue the following error on the console, stopping rendering altogether: script stack space quota is exhausted. Statement executed is: var match = quickExpr.exec( selector );\n from jquery.js?1.3.1 (line 50) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-502) Large objects/text crash Futon
[ https://issues.apache.org/jira/browse/COUCHDB-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-502: - Attachment: (was: test.json) Large objects/text crash Futon -- Key: COUCHDB-502 URL: https://issues.apache.org/jira/browse/COUCHDB-502 Project: CouchDB Issue Type: Bug Components: Administration Console Affects Versions: 0.9.1 Environment: Futon on Apache CouchDB 0.9.1, ubuntu Reporter: Jos Boumans Attachments: test.json.txt Any sufficiently large JSON object will cause script time outs in firefox/safari. The example object I used had 500 individual keys, whose values were hashes with 20 individual keys. Storing that same JSON ***AS STRING*** made firefox issue the following error on the console, stopping rendering altogether: script stack space quota is exhausted. Statement executed is: var match = quickExpr.exec( selector );\n from jquery.js?1.3.1 (line 50) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-502) Large objects/text crash the view server
[ https://issues.apache.org/jira/browse/COUCHDB-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12754982#action_12754982 ] Jason Davies commented on COUCHDB-502: -- I *think* it's a Futon issue. I would need to look into it to be sure though, perhaps it can be solved using some kind of lazy loading/rendering. We should also upgrade to jQuery 1.3.2, see COUCHDB-432. 1.3.2 has performance improvements related to :visible/:hidden selectors which may affect us, and it should improve performance generally. Large objects/text crash the view server Key: COUCHDB-502 URL: https://issues.apache.org/jira/browse/COUCHDB-502 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 0.9.1 Environment: Futon on Apache CouchDB 0.9.1, ubuntu Reporter: Jos Boumans Any sufficiently large JSON object will cause script time outs in firefox/safari. The example object I used had 500 individual keys, whose values were hashes with 20 individual keys. Storing that same JSON ***AS STRING*** made firefox issue the following error on the console, stopping rendering altogether: script stack space quota is exhausted. Statement executed is: var match = quickExpr.exec( selector );\n from jquery.js?1.3.1 (line 50) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-500) _list ignores endkey parameter
_list ignores endkey parameter -- Key: COUCHDB-500 URL: https://issues.apache.org/jira/browse/COUCHDB-500 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: endkey.test.patch endkey isn't tested at all in list_views.js at the moment, patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-500) _list ignores endkey parameter
[ https://issues.apache.org/jira/browse/COUCHDB-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-500: - Attachment: endkey.test.patch Simple patch demonstrating the problem. _list ignores endkey parameter -- Key: COUCHDB-500 URL: https://issues.apache.org/jira/browse/COUCHDB-500 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: endkey.test.patch endkey isn't tested at all in list_views.js at the moment, patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-500) _list ignores endkey parameter
[ https://issues.apache.org/jira/browse/COUCHDB-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-500: - Priority: Blocker (was: Major) _list ignores endkey parameter -- Key: COUCHDB-500 URL: https://issues.apache.org/jira/browse/COUCHDB-500 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Priority: Blocker Attachments: endkey.test.patch endkey isn't tested at all in list_views.js at the moment, patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-69) Allow selective retaining of older revisions to a document
[
https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12746585#action_12746585
]
Jason Davies commented on COUCHDB-69:
-
Thanks for the excellent feedback Damien.
Firstly, I thought that adding the old revinfos to the by_seq index would be a
relatively cheap operation, as we are simply taking them from
#doc_info{revs=Revs}, and this is already done for conflicts and deleted revs.
So I don't understand why my patch involves *reading* meta data for every old
rev from the disk when updating the by_seq index i.e. in this line:
HistoryRevInfos = if HistoryEnabled - [{Rev, Seq, Bp} ||
#rev_info{rev=Rev,seq=Seq,historical=true,body_sp=Bp} - Revs];
true - [] end,
But yes, it does mean that we are *storing* potentially 1000s of revs in this
index now, so I'm sure that would impact performance when updating the index.
With your second point in mind, I'm wondering whether it would be more
efficient to never delete old entries from the by_seq index (unless we purge),
thus saving us having to store all the old revs each time.
In response to your last point about multiple copies of attachments, this could
be solved if we kept an index of attachments by MD5 hash. I believe rnewson is
keen to get something like this in, so that if you upload the same attachment
to multiple docs, it only needs to store it once.
Allow selective retaining of older revisions to a document
--
Key: COUCHDB-69
URL: https://issues.apache.org/jira/browse/COUCHDB-69
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Environment: All
Reporter: Jan Lehnardt
Assignee: Paul Joseph Davis
Priority: Minor
Fix For: 0.10
Attachments: history_revs.2.patch, history_revs.3.patch,
history_revs.4.patch, history_revs.5.patch, history_revs.patch
At the moment, compaction gets rid of all old revisions of a document. Also,
replication also deals with the latest revision. It would be nice if it would
be possible to specify a list of revisions to keep around that do not get
compacted away and replicated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-479) HEAD requests fail with OAuth
HEAD requests fail with OAuth - Key: COUCHDB-479 URL: https://issues.apache.org/jira/browse/COUCHDB-479 Project: CouchDB Issue Type: Bug Reporter: Jason Davies Fix For: 0.10 Patch and test to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-479) HEAD requests fail with OAuth
[ https://issues.apache.org/jira/browse/COUCHDB-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745885#action_12745885 ] Jason Davies commented on COUCHDB-479: -- I hereby grant license to ASF for inclusion in ASF works (as per the Apache License ยง5) for my patch at http://friendpaste.com/2eZFpLM2byb1DtwijQxC3t . I have no idea why JIRA is timing out when I attempt to attach it to this ticket. HEAD requests fail with OAuth - Key: COUCHDB-479 URL: https://issues.apache.org/jira/browse/COUCHDB-479 Project: CouchDB Issue Type: Bug Reporter: Jason Davies Fix For: 0.10 Patch and test to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-478) Modify couch_httpd_auth:get_user to read from [admins] in .ini config and fall back to using database
[ https://issues.apache.org/jira/browse/COUCHDB-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-478: - Attachment: oauth_ini_users.3.patch Forgot to add X-Couch-Persist: false when deleting a config value. This also includes my fix for COUCHDB-479. Modify couch_httpd_auth:get_user to read from [admins] in .ini config and fall back to using database - Key: COUCHDB-478 URL: https://issues.apache.org/jira/browse/COUCHDB-478 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Jason Davies Fix For: 0.10 Attachments: oauth_ini_users.2.patch, oauth_ini_users.3.patch, oauth_ini_users.patch In the future we will make this pluggable (and orderable) but for now I think it is a sensible default to make oauth and cookie auth respect [admins] in the .ini as well as reading users from the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-478) Modify couch_httpd_auth:get_user to read from [admins] in .ini config and fall back to using database
Modify couch_httpd_auth:get_user to read from [admins] in .ini config and fall back to using database - Key: COUCHDB-478 URL: https://issues.apache.org/jira/browse/COUCHDB-478 Project: CouchDB Issue Type: Improvement Reporter: Jason Davies Fix For: 0.10 In the future we will make this pluggable (and orderable) but for now I think it is a sensible default to make oauth and cookie auth respect [admins] in the .ini as well as reading users from the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-478) Modify couch_httpd_auth:get_user to read from [admins] in .ini config and fall back to using database
[ https://issues.apache.org/jira/browse/COUCHDB-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-478: - Component/s: HTTP Interface Modify couch_httpd_auth:get_user to read from [admins] in .ini config and fall back to using database - Key: COUCHDB-478 URL: https://issues.apache.org/jira/browse/COUCHDB-478 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Jason Davies Fix For: 0.10 Attachments: oauth_ini_users.patch In the future we will make this pluggable (and orderable) but for now I think it is a sensible default to make oauth and cookie auth respect [admins] in the .ini as well as reading users from the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-69) Allow selective retaining of older revisions to a document
[ https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-69: Attachment: history_revs.5.patch Latest version of patch. Fixes bugs with replication. Allow selective retaining of older revisions to a document -- Key: COUCHDB-69 URL: https://issues.apache.org/jira/browse/COUCHDB-69 Project: CouchDB Issue Type: Improvement Components: Database Core Environment: All Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Minor Fix For: 0.10 Attachments: history_revs.2.patch, history_revs.3.patch, history_revs.4.patch, history_revs.5.patch, history_revs.patch At the moment, compaction gets rid of all old revisions of a document. Also, replication also deals with the latest revision. It would be nice if it would be possible to specify a list of revisions to keep around that do not get compacted away and replicated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-446) allow list function and view function to be in different design docs.
[ https://issues.apache.org/jira/browse/COUCHDB-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744013#action_12744013 ] Jason Davies commented on COUCHDB-446: -- Is there another use case for having separate design documents, aside from being able to use different languages for a view and a list? An alternative solution would be to allow a per-view/list language override, not sure how messy that would be in the query server handling, but it avoids the problem of design docs living on different nodes. But there may be other use cases that this patch solves too. allow list function and view function to be in different design docs. - Key: COUCHDB-446 URL: https://issues.apache.org/jira/browse/COUCHDB-446 Project: CouchDB Issue Type: New Feature Components: Database Core Reporter: Mark Hammond Fix For: 0.10 Attachments: x_doc_list.patch, x_doc_list_jan.patch There has been some discussion on #couchdb how it might be desirable to use a list function where the list and the view are in separate documents. Among the use-cases is so a list and view can use different languages. I'm attaching a patch which extends the URL syntax for list views - before my patch, the last portion of the path must be a view name. My patch allows for the existing behaviour, or for the tail to be 2 elements - another design document name *and* the view name. Includes a test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-470) Include peer in req object for lists, shows and updates
Include peer in req object for lists, shows and updates --- Key: COUCHDB-470 URL: https://issues.apache.org/jira/browse/COUCHDB-470 Project: CouchDB Issue Type: Improvement Reporter: Jason Davies Attachments: couch_httpd_external.peer.patch Simple one-liner. Useful for statistical tracking or any kind of IP-based switching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-470) Include peer in req object for lists, shows and updates
[ https://issues.apache.org/jira/browse/COUCHDB-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-470: - Attachment: couch_httpd_external.peer.patch Include peer in req object for lists, shows and updates --- Key: COUCHDB-470 URL: https://issues.apache.org/jira/browse/COUCHDB-470 Project: CouchDB Issue Type: Improvement Reporter: Jason Davies Attachments: couch_httpd_external.peer.patch Simple one-liner. Useful for statistical tracking or any kind of IP-based switching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-69) Allow selective retaining of older revisions to a document
[ https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-69: Attachment: history_revs.3.patch Latest patch with support for deleting old revs. My solution is that when history is turned on, the compactor will only delete old revs if they have doubled-up delete nodes, which won't occur normally. Doubled-up delete nodes can be created by deleting old revs and specifing ?forget=true as a query parameter. These double-up nodes should also get replicated. Would appreciate a review by someone. Allow selective retaining of older revisions to a document -- Key: COUCHDB-69 URL: https://issues.apache.org/jira/browse/COUCHDB-69 Project: CouchDB Issue Type: Improvement Components: Database Core Environment: All Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Minor Fix For: 0.10 Attachments: history_revs.2.patch, history_revs.3.patch, history_revs.patch At the moment, compaction gets rid of all old revisions of a document. Also, replication also deals with the latest revision. It would be nice if it would be possible to specify a list of revisions to keep around that do not get compacted away and replicated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-69) Allow selective retaining of older revisions to a document
[ https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-69: Attachment: (was: history_revs.4.patch) Allow selective retaining of older revisions to a document -- Key: COUCHDB-69 URL: https://issues.apache.org/jira/browse/COUCHDB-69 Project: CouchDB Issue Type: Improvement Components: Database Core Environment: All Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Minor Fix For: 0.10 Attachments: history_revs.2.patch, history_revs.3.patch, history_revs.patch At the moment, compaction gets rid of all old revisions of a document. Also, replication also deals with the latest revision. It would be nice if it would be possible to specify a list of revisions to keep around that do not get compacted away and replicated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-69) Allow selective retaining of older revisions to a document
[ https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-69: Attachment: history_revs.4.patch Patch against latest trunk. Allow selective retaining of older revisions to a document -- Key: COUCHDB-69 URL: https://issues.apache.org/jira/browse/COUCHDB-69 Project: CouchDB Issue Type: Improvement Components: Database Core Environment: All Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Minor Fix For: 0.10 Attachments: history_revs.2.patch, history_revs.3.patch, history_revs.patch At the moment, compaction gets rid of all old revisions of a document. Also, replication also deals with the latest revision. It would be nice if it would be possible to specify a list of revisions to keep around that do not get compacted away and replicated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-69) Allow selective retaining of older revisions to a document
[ https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-69: Attachment: history_revs.4.patch Patch against latest trunk. Allow selective retaining of older revisions to a document -- Key: COUCHDB-69 URL: https://issues.apache.org/jira/browse/COUCHDB-69 Project: CouchDB Issue Type: Improvement Components: Database Core Environment: All Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Minor Fix For: 0.10 Attachments: history_revs.2.patch, history_revs.3.patch, history_revs.4.patch, history_revs.patch At the moment, compaction gets rid of all old revisions of a document. Also, replication also deals with the latest revision. It would be nice if it would be possible to specify a list of revisions to keep around that do not get compacted away and replicated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-467) 500 error when accessing not found old revisions
500 error when accessing not found old revisions
--
Key: COUCHDB-467
URL: https://issues.apache.org/jira/browse/COUCHDB-467
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Attachments: old_revs_404.patch
The full error is {{not_found,missing}, {pos, revkey} and a 500 code is
returned because there is no pattern in error_info(...) for this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-69) Allow selective retaining of older revisions to a document
[ https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-69: Attachment: history_revs.patch First stab at allowing old revisions to survive compaction *and* be replicated. Note that this required a change to the by_seq B-tree. I'm still working on making this configurable: currently you need to set the HISTORY_ENABLED macro to true in couch_db.hrl for this to be turned on. Allow selective retaining of older revisions to a document -- Key: COUCHDB-69 URL: https://issues.apache.org/jira/browse/COUCHDB-69 Project: CouchDB Issue Type: Improvement Components: Database Core Environment: All Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Minor Fix For: 0.10 Attachments: history_revs.patch At the moment, compaction gets rid of all old revisions of a document. Also, replication also deals with the latest revision. It would be nice if it would be possible to specify a list of revisions to keep around that do not get compacted away and replicated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-69) Allow selective retaining of older revisions to a document
[ https://issues.apache.org/jira/browse/COUCHDB-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-69: Attachment: history_revs.2.patch Updated patch allowing per-db configuration. Allow selective retaining of older revisions to a document -- Key: COUCHDB-69 URL: https://issues.apache.org/jira/browse/COUCHDB-69 Project: CouchDB Issue Type: Improvement Components: Database Core Environment: All Reporter: Jan Lehnardt Assignee: Paul Joseph Davis Priority: Minor Fix For: 0.10 Attachments: history_revs.2.patch, history_revs.patch At the moment, compaction gets rid of all old revisions of a document. Also, replication also deals with the latest revision. It would be nice if it would be possible to specify a list of revisions to keep around that do not get compacted away and replicated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-441) Finally implement pre-write-doc-edit handlers.
[ https://issues.apache.org/jira/browse/COUCHDB-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-441: - Attachment: COUCHDB-441.3.patch Forgot to include new files share/server/update.js and share/www/script/test/updates.js. Included in this patch. Finally implement pre-write-doc-edit handlers. -- Key: COUCHDB-441 URL: https://issues.apache.org/jira/browse/COUCHDB-441 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.10 Reporter: Curt Arnold Fix For: 0.10 Attachments: COUCHDB-441.2.patch, COUCHDB-441.3.patch, COUCHDB-441.patch It would be useful for auditing to have the identity of the user who inserted a new revision and the timestamp of the operation to be inserted in the document in the same way that the new revision number is. Doing this at the application level is not adequate since it would be readily spoofable and would bypass the authentication handler. There is a comment in couch_db:update_docs about generating new revision ids, but I couldn't quite comprehend what specific code was responsible for inserting the id into the document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-460) Ensure reduce_limit is turned on for view_errors test
Ensure reduce_limit is turned on for view_errors test - Key: COUCHDB-460 URL: https://issues.apache.org/jira/browse/COUCHDB-460 Project: CouchDB Issue Type: Bug Reporter: Jason Davies Priority: Minor I get a spurious error if I have reduce_limit = false in my local.ini (yes, naughty I know). This simple patch turns on reduce_limit temporarily when running the view_errors test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-460) Ensure reduce_limit is turned on for view_errors test
[ https://issues.apache.org/jira/browse/COUCHDB-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-460: - Attachment: view_errors.js.patch Simple patch to turn on reduce_limit when running the view_errors test. Ensure reduce_limit is turned on for view_errors test - Key: COUCHDB-460 URL: https://issues.apache.org/jira/browse/COUCHDB-460 Project: CouchDB Issue Type: Bug Reporter: Jason Davies Priority: Minor Attachments: view_errors.js.patch I get a spurious error if I have reduce_limit = false in my local.ini (yes, naughty I know). This simple patch turns on reduce_limit temporarily when running the view_errors test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-459) License.txt for erlang-oauth
License.txt for erlang-oauth Key: COUCHDB-459 URL: https://issues.apache.org/jira/browse/COUCHDB-459 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: License.txt Thanks to Curt Arnold for pointing out the missing License.txt in erlang-oauth, please add the attached to src/erlang-oauth. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-459) License.txt for erlang-oauth
[ https://issues.apache.org/jira/browse/COUCHDB-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-459: - Attachment: License.txt License.txt for erlang-oauth Key: COUCHDB-459 URL: https://issues.apache.org/jira/browse/COUCHDB-459 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: License.txt Thanks to Curt Arnold for pointing out the missing License.txt in erlang-oauth, please add the attached to src/erlang-oauth. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-459) Licenses for erlang-oauth and ibrowse
[ https://issues.apache.org/jira/browse/COUCHDB-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-459: - Attachment: (was: License.txt) Licenses for erlang-oauth and ibrowse - Key: COUCHDB-459 URL: https://issues.apache.org/jira/browse/COUCHDB-459 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: LICENSE.patch Thanks to Curt Arnold for pointing out the missing licenses for erlang-oauth and ibrowse. See attached patch for the appropriate additions to be made to LICENSE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-459) Licenses for erlang-oauth and ibrowse
[ https://issues.apache.org/jira/browse/COUCHDB-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-459: - Description: Thanks to Curt Arnold for pointing out the missing licenses for erlang-oauth and ibrowse. See attached patch for the appropriate additions to be made to LICENSE. (was: Thanks to Curt Arnold for pointing out the missing License.txt in erlang-oauth, please add the attached to src/erlang-oauth.) Summary: Licenses for erlang-oauth and ibrowse (was: License.txt for erlang-oauth) Licenses for erlang-oauth and ibrowse - Key: COUCHDB-459 URL: https://issues.apache.org/jira/browse/COUCHDB-459 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: LICENSE.patch Thanks to Curt Arnold for pointing out the missing licenses for erlang-oauth and ibrowse. See attached patch for the appropriate additions to be made to LICENSE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-459) Licenses for erlang-oauth and ibrowse
[ https://issues.apache.org/jira/browse/COUCHDB-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-459: - Attachment: LICENSE.patch Patch with BSD licenses for src/erlang-oauth and src/ibrowse. Licenses for erlang-oauth and ibrowse - Key: COUCHDB-459 URL: https://issues.apache.org/jira/browse/COUCHDB-459 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: LICENSE.patch Thanks to Curt Arnold for pointing out the missing licenses for erlang-oauth and ibrowse. See attached patch for the appropriate additions to be made to LICENSE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-441) Finally implement pre-write-doc-edit handlers.
[ https://issues.apache.org/jira/browse/COUCHDB-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-441: - Attachment: COUCHDB-441.2.patch Updated patch that uses req.userCtx now that OAuth/cookie auth has landed. Finally implement pre-write-doc-edit handlers. -- Key: COUCHDB-441 URL: https://issues.apache.org/jira/browse/COUCHDB-441 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.10 Reporter: Curt Arnold Fix For: 0.10 Attachments: COUCHDB-441.2.patch, COUCHDB-441.patch It would be useful for auditing to have the identity of the user who inserted a new revision and the timestamp of the operation to be inserted in the document in the same way that the new revision number is. Doing this at the application level is not adequate since it would be readily spoofable and would bypass the authentication handler. There is a comment in couch_db:update_docs about generating new revision ids, but I couldn't quite comprehend what specific code was responsible for inserting the id into the document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-449) Turn off delayed commits by default
[ https://issues.apache.org/jira/browse/COUCHDB-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739403#action_12739403 ] Jason Davies commented on COUCHDB-449: -- +1. Can we make this a config setting? delayed_commits = false by default but can be turned on for a node for speed junkies. Turn off delayed commits by default --- Key: COUCHDB-449 URL: https://issues.apache.org/jira/browse/COUCHDB-449 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.9, 0.9.1 Reporter: Jan Lehnardt Priority: Blocker Fix For: 0.10 Delayed commits make CouchDB significantly faster. They also open a one second window for data loss. In 0.9 and trunk, delayed commits are enabled by default and can be overridden with HTTP headers and an explicit API call to flush the write buffer. I suggest to turn off delayed commits by default and use the same overrides to enable it per request. A per-database option is possible, too. One concern is developer workflow speed. The setting affects the test suite performance significantly. I'd opt to change couch.js to set the appropriate header to enable delayed commits for tests. CouchDB should guarantee data safety first and speed second, with sensible overrides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-453) If Accept: foo header is sent, server returns a render_error
If Accept: foo header is sent, server returns a render_error
--
Key: COUCHDB-453
URL: https://issues.apache.org/jira/browse/COUCHDB-453
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
The full error is: {error:render_error,reason:function raised error:
[object Object]}
This occurs because there is no match for the foo mime type. Simple patch to
follow that makes us fall back to sending the first mime type provided. Be
conservative in what you send, liberal in what you accept.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-453) If Accept: foo header is sent, server returns a render_error
[
https://issues.apache.org/jira/browse/COUCHDB-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-453:
-
Attachment: render.js.patch
Fall back to first mime type provided if we can't match what is in the Accept
header.
If Accept: foo header is sent, server returns a render_error
--
Key: COUCHDB-453
URL: https://issues.apache.org/jira/browse/COUCHDB-453
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Attachments: render.js.patch
The full error is: {error:render_error,reason:function raised error:
[object Object]}
This occurs because there is no match for the foo mime type. Simple patch
to follow that makes us fall back to sending the first mime type provided.
Be conservative in what you send, liberal in what you accept.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-453) If Accept: foo header is sent, server returns a render_error
[
https://issues.apache.org/jira/browse/COUCHDB-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-453:
-
Attachment: render.js.patch
Updated patch with test case (looks like there was a test case for this but it
wasn't written correctly - fixed).
If Accept: foo header is sent, server returns a render_error
--
Key: COUCHDB-453
URL: https://issues.apache.org/jira/browse/COUCHDB-453
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Attachments: render.js.patch
The full error is: {error:render_error,reason:function raised error:
[object Object]}
This occurs because there is no match for the foo mime type. Simple patch
to follow that makes us fall back to sending the first mime type provided.
Be conservative in what you send, liberal in what you accept.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-453) If Accept: foo header is sent, server returns a render_error
[
https://issues.apache.org/jira/browse/COUCHDB-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-453:
-
Attachment: (was: render.js.patch)
If Accept: foo header is sent, server returns a render_error
--
Key: COUCHDB-453
URL: https://issues.apache.org/jira/browse/COUCHDB-453
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Attachments: render.js.patch
The full error is: {error:render_error,reason:function raised error:
[object Object]}
This occurs because there is no match for the foo mime type. Simple patch
to follow that makes us fall back to sending the first mime type provided.
Be conservative in what you send, liberal in what you accept.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-453) If Accept: foo header is sent, server returns a render_error
[
https://issues.apache.org/jira/browse/COUCHDB-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739804#action_12739804
]
Jason Davies commented on COUCHDB-453:
--
I meant the first. However, I didn't realise that Chris had originally
intended to return a 406 response, which upon reflection is the preferred
solution as you point out. It just wasn't working properly and sent a 500
render_error instead. He has now fixed it and it returns a 406, so I think
we are all in agreement now. Thanks for your attention to detail!
If Accept: foo header is sent, server returns a render_error
--
Key: COUCHDB-453
URL: https://issues.apache.org/jira/browse/COUCHDB-453
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Attachments: render.js.patch
The full error is: {error:render_error,reason:function raised error:
[object Object]}
This occurs because there is no match for the foo mime type. Simple patch
to follow that makes us fall back to sending the first mime type provided.
Be conservative in what you send, liberal in what you accept.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-450) Chunk size bug in ibrowse v1.5.2 manifesting as {error:replicated_attachment_too_large} when replicating
Chunk size bug in ibrowse v1.5.2 manifesting as
{error:replicated_attachment_too_large} when replicating
--
Key: COUCHDB-450
URL: https://issues.apache.org/jira/browse/COUCHDB-450
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Fix For: 0.10
Attachments: ibrowse_chunk_size.patch
Patch to follow...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-450) Chunk size bug in ibrowse v1.5.2 manifesting as {error:replicated_attachment_too_large} when replicating
[
https://issues.apache.org/jira/browse/COUCHDB-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-450:
-
Attachment: ibrowse_chunk_size.patch
Chunk size bug in ibrowse v1.5.2 manifesting as
{error:replicated_attachment_too_large} when replicating
--
Key: COUCHDB-450
URL: https://issues.apache.org/jira/browse/COUCHDB-450
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Fix For: 0.10
Attachments: ibrowse_chunk_size.patch
Patch to follow...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-450) Chunk size bug in ibrowse v1.5.2 manifesting as {error:replicated_attachment_too_large} when replicating
[
https://issues.apache.org/jira/browse/COUCHDB-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-450:
-
Priority: Blocker (was: Major)
Chunk size bug in ibrowse v1.5.2 manifesting as
{error:replicated_attachment_too_large} when replicating
--
Key: COUCHDB-450
URL: https://issues.apache.org/jira/browse/COUCHDB-450
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Priority: Blocker
Fix For: 0.10
Attachments: ibrowse_chunk_size.patch
Patch to follow...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-451) Upgrade to ibrowse 1.5.2
Upgrade to ibrowse 1.5.2 Key: COUCHDB-451 URL: https://issues.apache.org/jira/browse/COUCHDB-451 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Jason Davies Fix For: 0.10 From the commit message: The ETS table created for load balancing of requests was not being deleted which led to the node not being able to create any more ETS tables if queries were made to many number of webservers. ibrowse now deletes the ETS table it creates once the last connection to a webserver is dropped. (Reported by Seth Falcon.) Patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-451) Upgrade to ibrowse 1.5.2
[ https://issues.apache.org/jira/browse/COUCHDB-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-451: - Attachment: ibrowse.1.5.2.patch ibrowse 1.5.2. Upgrade to ibrowse 1.5.2 Key: COUCHDB-451 URL: https://issues.apache.org/jira/browse/COUCHDB-451 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Jason Davies Fix For: 0.10 Attachments: ibrowse.1.5.2.patch From the commit message: The ETS table created for load balancing of requests was not being deleted which led to the node not being able to create any more ETS tables if queries were made to many number of webservers. ibrowse now deletes the ETS table it creates once the last connection to a webserver is dropped. (Reported by Seth Falcon.) Patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-441) Finally implement pre-write-doc-edit handlers.
[ https://issues.apache.org/jira/browse/COUCHDB-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738023#action_12738023 ] Jason Davies commented on COUCHDB-441: -- Nice work Paul! One thing I noticed about your patch is that _update expects a JSON body in the request. Can we remove this requirement and make it so the function signature is simply (doc, req, userCtx)? In my oauth branch I've modified couch_httpd_external.erl to always populate req.userCtx so the function signature will be even shorter when this gets merged. Then we can do fun things like handle XML bodies in the request. Finally implement pre-write-doc-edit handlers. -- Key: COUCHDB-441 URL: https://issues.apache.org/jira/browse/COUCHDB-441 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.10 Reporter: Curt Arnold Fix For: 0.10 Attachments: COUCHDB-441.patch It would be useful for auditing to have the identity of the user who inserted a new revision and the timestamp of the operation to be inserted in the document in the same way that the new revision number is. Doing this at the application level is not adequate since it would be readily spoofable and would bypass the authentication handler. There is a comment in couch_db:update_docs about generating new revision ids, but I couldn't quite comprehend what specific code was responsible for inserting the id into the document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-441) Finally implement pre-write-doc-edit handlers.
[
https://issues.apache.org/jira/browse/COUCHDB-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738096#action_12738096
]
Jason Davies commented on COUCHDB-441:
--
The other thing I forgot to mention is that I would like the function to return
an arbitrary response body too, so the function would be something like:
function(doc, req) {
// do some processing on doc
return {doc: doc, body: body, headers: headers};
}
Finally implement pre-write-doc-edit handlers.
--
Key: COUCHDB-441
URL: https://issues.apache.org/jira/browse/COUCHDB-441
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Affects Versions: 0.10
Reporter: Curt Arnold
Fix For: 0.10
Attachments: COUCHDB-441.patch
It would be useful for auditing to have the identity of the user who inserted
a new revision and the timestamp of the operation to be inserted in the
document in the same way that the new revision number is.
Doing this at the application level is not adequate since it would be readily
spoofable and would bypass the authentication handler.
There is a comment in couch_db:update_docs about generating new revision ids,
but I couldn't quite comprehend what specific code was responsible for
inserting the id into the document.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-263) require valid user for all database operations
[ https://issues.apache.org/jira/browse/COUCHDB-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12737097#action_12737097 ] Jason Davies commented on COUCHDB-263: -- I've absorbed this patch into my oauth branch at http://github.com/jasondavies/couchdb/tree/oauth . I've modified it as follows: 1. The setting has been moved to [couch_httpd_auth] require_valid_user = true 2. The setting affects all authentication handlers instance-wide. If none of them set user_ctx, then a 401 error is returned when require_valid_user = true. require valid user for all database operations -- Key: COUCHDB-263 URL: https://issues.apache.org/jira/browse/COUCHDB-263 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.9 Environment: All platforms. Reporter: Jack Moffitt Priority: Blocker Fix For: 0.10 Attachments: couchauth.diff Admin accounts currently restrict a few operations, but leave all other operations completely open. Many use cases will require all operations to be authenticated. This can certainly be done by overriding the default_authentication_handler, but I think this very common use case can be handled in default_authentication_handler without increasing the complexity much. Attached is a patch which adds a new config option, require_valid_user, which restricts all operations to authenticated users only. Since CouchDB currently only has admins, this means that all operations are restricted to admins. In a future CouchDB where there are also normal users, the intention is that this would let them pass through as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-429) Wrong rows shown when clicking previous in Futon for reduce views
[ https://issues.apache.org/jira/browse/COUCHDB-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-429: - Priority: Blocker (was: Major) Wrong rows shown when clicking previous in Futon for reduce views --- Key: COUCHDB-429 URL: https://issues.apache.org/jira/browse/COUCHDB-429 Project: CouchDB Issue Type: Bug Components: Administration Console Reporter: Jason Davies Assignee: Christopher Lenz Priority: Blocker Fix For: 0.10 Attachments: futon.browse.js.2.patch, futon.browse.js.patch Click next twice, and then click previous twice, and it only shows 9 rows on the first page (less if you click next more times). This is due to the extra row being put in the wrong place when clicking previous. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[
https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-420:
-
Attachment: oauth.2.patch
Latest patch with code cleanups and a couple of bug fixes.
OAuth authentication support (2-legged initially) and cookie-based
authentication
-
Key: COUCHDB-420
URL: https://issues.apache.org/jira/browse/COUCHDB-420
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Reporter: Jason Davies
Fix For: 0.10
Attachments: oauth.1.diff, oauth.2.patch
This patch adds two-legged OAuth support to CouchDB.
1. In order to do this, a couple of changes have been made to the way auth
handlers are used. Essentially, the patch allows multiple handlers to be
specified in a comma-separated list in the following in the [httpd] section
of your .ini config e.g.
authentication_handlers = {couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
The handlers are tried in order until one of them successfully authenticates
and sets user_ctx on the request. Then the request is passed to the main
handler.
2. Now for the OAuth consumer keys and secrets: as Ubuntu need to be able to
bootstrap this i.e. add tokens without a running CouchDB, I have advised
creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini
or similar. This should get read by CouchDB's startup script when it loads
its config files (e.g. default.ini and local.ini as well). There are three
sections available:
i. [oauth_consumer_secrets] consumer_key = consumer_secret
ii. [oauth_token_secrets] oauth_token = oauth_token_secret
iii. [oauth_token_users] oauth_token = username
The format I've used above is [section name] followed by how the keys and
values for that section will look on subsequent lines. The secrets are a way
for the consumer to prove that it owns the corresponding consumer key or
access token. The mapping of auth tokens to usernames is a way to specify
which user/roles to give to a consumer with a given access token.
In the future we will also store tokens in the user database (see below).
3. OAuth replication. I've extended the JSON sent via POST when initiating a
replication as follows:
{
source: {
url: url,
auth: {
oauth: {
consumer_key: oauth_consumer_key,
consumer_secret: oauth_consumer_secret,
token_secret: oauth_token_secret,
token: oauth_token
}
}
},
target: /* same syntax as source, or string for a URL with no auth info, or
string for local database name */
}
4. This patch also includes cookie-authentication support to CouchDB. I've
covered this here:
http://www.jasondavies.com/blog/2009/05/27/secure-cookie-authentication-couchdb/
The cookie-authentication branch is being used on a couple of live sites and
the branch has also been worked on by jchris and benoitc. As well as cookie
auth it includes the beginnings of support for a per-node user database, with
APIs for creating/deleting users etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-437) Make compression level configurable, and allow attachments to be compressed
Make compression level configurable, and allow attachments to be compressed --- Key: COUCHDB-437 URL: https://issues.apache.org/jira/browse/COUCHDB-437 Project: CouchDB Issue Type: Improvement Components: Database Core Reporter: Jason Davies Priority: Minor As suggested by Adam Kocolosk in http://www.mail-archive.com/dev@couchdb.apache.org/msg02858.html The nice thing is that binary_to_term seems perfectly happy reading a mix of compressed and uncompressed binaries, which means the compression level can be a configuration parameter if we want it to be. gzip decompresses pretty quickly, so I'm guessing that reading a compressed DB will be faster than an uncompressed one. We'll have to measure it, though. Just thinking that space may be at a premium for some users and enabling compression could save them quite a bit of space depending on the data stored in docs. Compressing attachments could be beneficial too, and for particular use cases compression might increase read throughput due to needing less disk reads. As Adam says, we need to measure it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-426) Sort view names alphabetically in Futon
Sort view names alphabetically in Futon --- Key: COUCHDB-426 URL: https://issues.apache.org/jira/browse/COUCHDB-426 Project: CouchDB Issue Type: Improvement Components: Administration Console Reporter: Jason Davies Fix For: 0.10 Attachments: futon.browse.js.diff Simple patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-426) Sort view names alphabetically in Futon
[ https://issues.apache.org/jira/browse/COUCHDB-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-426: - Attachment: futon.browse.js.2.diff Better patch that also sorts design docs in alphabetical order and reduces number of HTTP requests. Sort view names alphabetically in Futon --- Key: COUCHDB-426 URL: https://issues.apache.org/jira/browse/COUCHDB-426 Project: CouchDB Issue Type: Improvement Components: Administration Console Reporter: Jason Davies Fix For: 0.10 Attachments: futon.browse.js.2.diff, futon.browse.js.diff Simple patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-429) Wrong rows shown when clicking previous in Futon for reduce views
Wrong rows shown when clicking previous in Futon for reduce views --- Key: COUCHDB-429 URL: https://issues.apache.org/jira/browse/COUCHDB-429 Project: CouchDB Issue Type: Bug Components: Administration Console Reporter: Jason Davies Fix For: 0.10 Attachments: futon.browse.js.patch Click next twice, and then click previous twice, and it only shows 9 rows on the first page (less if you click next more times). This is due to the extra row being put in the wrong place when clicking previous. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-429) Wrong rows shown when clicking previous in Futon for reduce views
[ https://issues.apache.org/jira/browse/COUCHDB-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-429: - Attachment: futon.browse.js.patch Wrong rows shown when clicking previous in Futon for reduce views --- Key: COUCHDB-429 URL: https://issues.apache.org/jira/browse/COUCHDB-429 Project: CouchDB Issue Type: Bug Components: Administration Console Reporter: Jason Davies Fix For: 0.10 Attachments: futon.browse.js.patch Click next twice, and then click previous twice, and it only shows 9 rows on the first page (less if you click next more times). This is due to the extra row being put in the wrong place when clicking previous. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
OAuth authentication support (2-legged initially) and cookie-based
authentication
-
Key: COUCHDB-420
URL: https://issues.apache.org/jira/browse/COUCHDB-420
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Reporter: Jason Davies
Fix For: 0.10
This patch adds OAuth support to CouchDB.
In order to do this, a couple of changes have been made to the way auth
handlers are used. Essentially, the patch allows multiple handlers to be
specified in a comma-separated list in the following in the [httpd] section of
your .ini config e.g.
authentication_handlers = {couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
2. Now for the OAuth consumer keys and secrets: for Ubuntu I would advise
creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini
or similar. This should get read by CouchDB's startup script when it loads its
config files (e.g. default.ini and local.ini as well). There are three
sections available:
i. [oauth_consumer_secrets] consumer_key = consumer_secret
ii. [oauth_token_secrets] oauth_token = oauth_token_secret
iii. [oauth_token_users] oauth_token = username
The format I've used above is [section name] followed by how the keys and
values for that section will look on subsequent lines. The secrets are a way
for the consumer to prove that it owns the corresponding consumer key or access
token. The mapping of auth tokens to usernames is a way to specify which
user/roles to give to a consumer with a given access token.
3. OAuth replication. I've extended the JSON sent via POST when initiating a
replication as follows:
{
source: {
url: url,
auth: {
oauth: {
consumer_key: oauth_consumer_key,
consumer_secret: oauth_consumer_secret,
token_secret: oauth_token_secret,
token: oauth_token
}
}
},
target: /* same syntax as source, or string for a URL with no auth info, or
string for local database name */
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[
https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-420:
-
Description:
This patch adds two-legged OAuth support to CouchDB.
1. In order to do this, a couple of changes have been made to the way auth
handlers are used. Essentially, the patch allows multiple handlers to be
specified in a comma-separated list in the following in the [httpd] section of
your .ini config e.g.
authentication_handlers = {couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
The handlers are tried in order until one of them successfully authenticates
and sets user_ctx on the request. Then the request is passed to the main
handler.
2. Now for the OAuth consumer keys and secrets: as Ubuntu need to be able to
bootstrap this i.e. add tokens without a running CouchDB, I have advised
creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini
or similar. This should get read by CouchDB's startup script when it loads its
config files (e.g. default.ini and local.ini as well). There are three
sections available:
i. [oauth_consumer_secrets] consumer_key = consumer_secret
ii. [oauth_token_secrets] oauth_token = oauth_token_secret
iii. [oauth_token_users] oauth_token = username
The format I've used above is [section name] followed by how the keys and
values for that section will look on subsequent lines. The secrets are a way
for the consumer to prove that it owns the corresponding consumer key or access
token. The mapping of auth tokens to usernames is a way to specify which
user/roles to give to a consumer with a given access token.
In the future we will also store tokens in the user database (see below).
3. OAuth replication. I've extended the JSON sent via POST when initiating a
replication as follows:
{
source: {
url: url,
auth: {
oauth: {
consumer_key: oauth_consumer_key,
consumer_secret: oauth_consumer_secret,
token_secret: oauth_token_secret,
token: oauth_token
}
}
},
target: /* same syntax as source, or string for a URL with no auth info, or
string for local database name */
}
4. This patch also includes cookie-authentication support to CouchDB. I've
covered this here:
http://www.jasondavies.com/blog/2009/05/27/secure-cookie-authentication-couchdb/
The cookie-authentication branch is being used on a couple of live sites and
the branch has also been worked on by jchris and benoitc. As well as cookie
auth it includes the beginnings of support for a per-node user database, with
APIs for creating/deleting users etc.
was:
This patch adds OAuth support to CouchDB.
In order to do this, a couple of changes have been made to the way auth
handlers are used. Essentially, the patch allows multiple handlers to be
specified in a comma-separated list in the following in the [httpd] section of
your .ini config e.g.
authentication_handlers = {couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
2. Now for the OAuth consumer keys and secrets: for Ubuntu I would advise
creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini
or similar. This should get read by CouchDB's startup script when it loads its
config files (e.g. default.ini and local.ini as well). There are three
sections available:
i. [oauth_consumer_secrets] consumer_key = consumer_secret
ii. [oauth_token_secrets] oauth_token = oauth_token_secret
iii. [oauth_token_users] oauth_token = username
The format I've used above is [section name] followed by how the keys and
values for that section will look on subsequent lines. The secrets are a way
for the consumer to prove that it owns the corresponding consumer key or access
token. The mapping of auth tokens to usernames is a way to specify which
user/roles to give to a consumer with a given access token.
3. OAuth replication. I've extended the JSON sent via POST when initiating a
replication as follows:
{
source: {
url: url,
auth: {
oauth: {
consumer_key: oauth_consumer_key,
consumer_secret: oauth_consumer_secret,
token_secret: oauth_token_secret,
token: oauth_token
}
}
},
target: /* same syntax as source, or string for a URL with no auth info, or
string for local database name */
}
OAuth authentication support (2-legged initially) and cookie-based
authentication
-
Key: COUCHDB-420
URL: https://issues.apache.org/jira/browse/COUCHDB-420
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Reporter: Jason Davies
Fix For: 0.10
This patch adds two-legged OAuth support to CouchDB.
1. In order to do
[jira] Updated: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[
https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-420:
-
Attachment: oauth.1.diff
Patch for review.
OAuth authentication support (2-legged initially) and cookie-based
authentication
-
Key: COUCHDB-420
URL: https://issues.apache.org/jira/browse/COUCHDB-420
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Reporter: Jason Davies
Fix For: 0.10
Attachments: oauth.1.diff
This patch adds two-legged OAuth support to CouchDB.
1. In order to do this, a couple of changes have been made to the way auth
handlers are used. Essentially, the patch allows multiple handlers to be
specified in a comma-separated list in the following in the [httpd] section
of your .ini config e.g.
authentication_handlers = {couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
The handlers are tried in order until one of them successfully authenticates
and sets user_ctx on the request. Then the request is passed to the main
handler.
2. Now for the OAuth consumer keys and secrets: as Ubuntu need to be able to
bootstrap this i.e. add tokens without a running CouchDB, I have advised
creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini
or similar. This should get read by CouchDB's startup script when it loads
its config files (e.g. default.ini and local.ini as well). There are three
sections available:
i. [oauth_consumer_secrets] consumer_key = consumer_secret
ii. [oauth_token_secrets] oauth_token = oauth_token_secret
iii. [oauth_token_users] oauth_token = username
The format I've used above is [section name] followed by how the keys and
values for that section will look on subsequent lines. The secrets are a way
for the consumer to prove that it owns the corresponding consumer key or
access token. The mapping of auth tokens to usernames is a way to specify
which user/roles to give to a consumer with a given access token.
In the future we will also store tokens in the user database (see below).
3. OAuth replication. I've extended the JSON sent via POST when initiating a
replication as follows:
{
source: {
url: url,
auth: {
oauth: {
consumer_key: oauth_consumer_key,
consumer_secret: oauth_consumer_secret,
token_secret: oauth_token_secret,
token: oauth_token
}
}
},
target: /* same syntax as source, or string for a URL with no auth info, or
string for local database name */
}
4. This patch also includes cookie-authentication support to CouchDB. I've
covered this here:
http://www.jasondavies.com/blog/2009/05/27/secure-cookie-authentication-couchdb/
The cookie-authentication branch is being used on a couple of live sites and
the branch has also been worked on by jchris and benoitc. As well as cookie
auth it includes the beginnings of support for a per-node user database, with
APIs for creating/deleting users etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-409) $.couch.saveDoc() in jquery.couch.js sets doc._id and doc._rev to undefined on error, causing a new doc to be created if the same doc is modified and saved again
[ https://issues.apache.org/jira/browse/COUCHDB-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-409: - Attachment: jquery.couch.saveDoc.diff $.couch.saveDoc() in jquery.couch.js sets doc._id and doc._rev to undefined on error, causing a new doc to be created if the same doc is modified and saved again - Key: COUCHDB-409 URL: https://issues.apache.org/jira/browse/COUCHDB-409 Project: CouchDB Issue Type: Bug Components: Administration Console Affects Versions: 0.9.1, 0.10 Reporter: Jason Davies Fix For: 0.9.1 Attachments: jquery.couch.saveDoc.diff Simple fix attached. Recommend that we include this in 0.9.1 as it's a non-obvious annoyance that occurs when saving docs in Futon. For example, if I try and save a doc and validation fails, and I fix the doc and save again, it will be saved with a NEW document id, since doc._id is set to undefined. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-410) JavaScript errors in validate_doc_update should be handled more gracefully
JavaScript errors in validate_doc_update should be handled more gracefully
--
Key: COUCHDB-410
URL: https://issues.apache.org/jira/browse/COUCHDB-410
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.9.1, 0.10
Reporter: Jason Davies
Fix For: 0.9.1
For example, if I create validate_doc_update:
function (oldDoc, newDoc, userCtx) {
doc.myUndefinedProperty;
}
I am greeted by an OS process timed out message. In the logs, all I see is:
OS Process :: Error converting object to JSON: TypeError: {Array:function (v)
{var buf = [];for (var i = 0; i v.length; i++)
{buf.push(toJSON(v[i]));}return [ + buf.join(,) + ];}, Boolean:function
(v) {return v.toString();}, Date:function (v) {var f = function (n) {return n
10 ? 0 + n : n;};return \ + v.getUTCFullYear() + - + f(v.getUTCMonth() +
1) + - + f(v.getUTCDate()) + T + f(v.getUTCHours()) + : +
f(v.getUTCMinutes()) + : + f(v.getUTCSeconds()) + Z\;}, Number:function
(v) {return isFinite(v) ? v.toString() : null;}, Object:function (v) {if (v
=== null) {return null;}var buf = [];for (var k in v) {if
(!v.hasOwnProperty(k) || typeof k !== string || v[k] === undefined)
{continue;}buf.push(toJSON(k, val) + : + toJSON(v[k]));}return { +
buf.join(,) + };}, String:function (v) {if (/[\\\x00-\x1f]/.test(v)) {v =
v.replace(/([\x00-\x1f\\])/g, function (a, b) {var c = subs[b];if (c) {return
c;}c = b.charCodeAt();return \\u00 + Math.floor(c / 16).toString(16) + (c %
16).toString(16);});}return \ + v + \;}}[val != null ?
val.constructor.name : Object] is not a function
When really the problem is a ReferenceError. The attached patch modifies
toJSON() in utils.js so that it converts anything that isn't a String, Array,
Date, Object etc. into a String. This makes the error appear in the popup in
Futon when saving.
This isn't necessarily the best thing to do as it modifies the semantics of
toJSON(), and also we might want to keep the exception info in the logs, and
not propagate it to the user. Perhaps it would be better to modify
respond(obj) to produce a better error message in the logs (simply adding
something that tried to log obj.toString() would suffice).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-410) JavaScript errors in validate_doc_update should be handled more gracefully
[
https://issues.apache.org/jira/browse/COUCHDB-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-410:
-
Attachment: util.js.diff
Patch that modifies toJSON() so that toJSON(ReferenceError(doc.foo is not
defined)) works.
JavaScript errors in validate_doc_update should be handled more gracefully
--
Key: COUCHDB-410
URL: https://issues.apache.org/jira/browse/COUCHDB-410
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.9.1, 0.10
Reporter: Jason Davies
Fix For: 0.9.1
Attachments: util.js.diff
For example, if I create validate_doc_update:
function (oldDoc, newDoc, userCtx) {
doc.myUndefinedProperty;
}
I am greeted by an OS process timed out message. In the logs, all I see is:
OS Process :: Error converting object to JSON: TypeError: {Array:function (v)
{var buf = [];for (var i = 0; i v.length; i++)
{buf.push(toJSON(v[i]));}return [ + buf.join(,) + ];}, Boolean:function
(v) {return v.toString();}, Date:function (v) {var f = function (n) {return n
10 ? 0 + n : n;};return \ + v.getUTCFullYear() + - +
f(v.getUTCMonth() + 1) + - + f(v.getUTCDate()) + T + f(v.getUTCHours()) +
: + f(v.getUTCMinutes()) + : + f(v.getUTCSeconds()) + Z\;},
Number:function (v) {return isFinite(v) ? v.toString() : null;},
Object:function (v) {if (v === null) {return null;}var buf = [];for (var k
in v) {if (!v.hasOwnProperty(k) || typeof k !== string || v[k] ===
undefined) {continue;}buf.push(toJSON(k, val) + : + toJSON(v[k]));}return
{ + buf.join(,) + };}, String:function (v) {if
(/[\\\x00-\x1f]/.test(v)) {v = v.replace(/([\x00-\x1f\\])/g, function (a,
b) {var c = subs[b];if (c) {return c;}c = b.charCodeAt();return \\u00 +
Math.floor(c / 16).toString(16) + (c % 16).toString(16);});}return \ + v +
\;}}[val != null ? val.constructor.name : Object] is not a function
When really the problem is a ReferenceError. The attached patch modifies
toJSON() in utils.js so that it converts anything that isn't a String, Array,
Date, Object etc. into a String. This makes the error appear in the popup in
Futon when saving.
This isn't necessarily the best thing to do as it modifies the semantics of
toJSON(), and also we might want to keep the exception info in the logs, and
not propagate it to the user. Perhaps it would be better to modify
respond(obj) to produce a better error message in the logs (simply adding
something that tried to log obj.toString() would suffice).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-410) JavaScript errors in validate_doc_update should be handled more gracefully
[
https://issues.apache.org/jira/browse/COUCHDB-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-410:
-
Description:
For example, if I create validate_doc_update:
function (oldDoc, newDoc, userCtx) {
doc.foo;
}
I am greeted by an OS process timed out message. In the logs, all I see is:
OS Process :: Error converting object to JSON: TypeError: {Array:function (v)
{var buf = [];for (var i = 0; i v.length; i++)
{buf.push(toJSON(v[i]));}return [ + buf.join(,) + ];}, Boolean:function
(v) {return v.toString();}, Date:function (v) {var f = function (n) {return n
10 ? 0 + n : n;};return \ + v.getUTCFullYear() + - + f(v.getUTCMonth() +
1) + - + f(v.getUTCDate()) + T + f(v.getUTCHours()) + : +
f(v.getUTCMinutes()) + : + f(v.getUTCSeconds()) + Z\;}, Number:function
(v) {return isFinite(v) ? v.toString() : null;}, Object:function (v) {if (v
=== null) {return null;}var buf = [];for (var k in v) {if
(!v.hasOwnProperty(k) || typeof k !== string || v[k] === undefined)
{continue;}buf.push(toJSON(k, val) + : + toJSON(v[k]));}return { +
buf.join(,) + };}, String:function (v) {if (/[\\\x00-\x1f]/.test(v)) {v =
v.replace(/([\x00-\x1f\\])/g, function (a, b) {var c = subs[b];if (c) {return
c;}c = b.charCodeAt();return \\u00 + Math.floor(c / 16).toString(16) + (c %
16).toString(16);});}return \ + v + \;}}[val != null ?
val.constructor.name : Object] is not a function
When really the problem is a ReferenceError (I should have used newDoc.foo or
oldDoc.foo). The attached patch modifies toJSON() in utils.js so that it
converts anything that isn't a String, Array, Date, Object etc. into a String.
This makes the error appear in the popup in Futon when saving.
This isn't necessarily the best thing to do as it modifies the semantics of
toJSON(), and also we might want to keep the exception info in the logs, and
not propagate it to the user. Perhaps it would be better to modify
respond(obj) to produce a better error message in the logs (simply adding
something that tried to log obj.toString() would suffice).
was:
For example, if I create validate_doc_update:
function (oldDoc, newDoc, userCtx) {
doc.myUndefinedProperty;
}
I am greeted by an OS process timed out message. In the logs, all I see is:
OS Process :: Error converting object to JSON: TypeError: {Array:function (v)
{var buf = [];for (var i = 0; i v.length; i++)
{buf.push(toJSON(v[i]));}return [ + buf.join(,) + ];}, Boolean:function
(v) {return v.toString();}, Date:function (v) {var f = function (n) {return n
10 ? 0 + n : n;};return \ + v.getUTCFullYear() + - + f(v.getUTCMonth() +
1) + - + f(v.getUTCDate()) + T + f(v.getUTCHours()) + : +
f(v.getUTCMinutes()) + : + f(v.getUTCSeconds()) + Z\;}, Number:function
(v) {return isFinite(v) ? v.toString() : null;}, Object:function (v) {if (v
=== null) {return null;}var buf = [];for (var k in v) {if
(!v.hasOwnProperty(k) || typeof k !== string || v[k] === undefined)
{continue;}buf.push(toJSON(k, val) + : + toJSON(v[k]));}return { +
buf.join(,) + };}, String:function (v) {if (/[\\\x00-\x1f]/.test(v)) {v =
v.replace(/([\x00-\x1f\\])/g, function (a, b) {var c = subs[b];if (c) {return
c;}c = b.charCodeAt();return \\u00 + Math.floor(c / 16).toString(16) + (c %
16).toString(16);});}return \ + v + \;}}[val != null ?
val.constructor.name : Object] is not a function
When really the problem is a ReferenceError. The attached patch modifies
toJSON() in utils.js so that it converts anything that isn't a String, Array,
Date, Object etc. into a String. This makes the error appear in the popup in
Futon when saving.
This isn't necessarily the best thing to do as it modifies the semantics of
toJSON(), and also we might want to keep the exception info in the logs, and
not propagate it to the user. Perhaps it would be better to modify
respond(obj) to produce a better error message in the logs (simply adding
something that tried to log obj.toString() would suffice).
Clarified what the error is in my example.
JavaScript errors in validate_doc_update should be handled more gracefully
--
Key: COUCHDB-410
URL: https://issues.apache.org/jira/browse/COUCHDB-410
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.9.1, 0.10
Reporter: Jason Davies
Fix For: 0.9.1
Attachments: util.js.diff
For example, if I create validate_doc_update:
function (oldDoc, newDoc, userCtx) {
doc.foo;
}
I am greeted by an OS process timed out message. In the logs, all I see is:
OS Process :: Error converting object to JSON: TypeError: {Array:function (v)
{var buf = [];for (var i = 0; i v.length; i++)
{buf.push(toJSON(v[i]));}return [ + buf.join(,) + ];}, Boolean:function
(v) {return v.toString();},
[jira] Created: (COUCHDB-340) Canonical URLs: Issue redirects where appropriate
Canonical URLs: Issue redirects where appropriate - Key: COUCHDB-340 URL: https://issues.apache.org/jira/browse/COUCHDB-340 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Jason Davies Priority: Minor We should issue a redirect from http://127.0.0.1:5984/dbname - http://127.0.0.1:5984/dbname/ (note trailing slash) as the latter seems more appropriate to represent the hierarchy. As for document URLs, I am thinking they should probably also have a trailing slash, as it is possible to have document attachments at the next level of the hierarchy. When using _show, this would also mean links to attachments would be simpler. As for view URLs (and _list), I don't see any reason for them to have trailing slashes. In these cases, we should probably issue a 301 to the non-trailing-slash URL, or issue a 404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-341) No way to reconstruct true path in _list and _show functions
No way to reconstruct true path in _list and _show functions Key: COUCHDB-341 URL: https://issues.apache.org/jira/browse/COUCHDB-341 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Jason Davies Priority: Minor The req.path variable is a list of path components. However, it is impossible, for example, to tell whether the actual path ends in '/' or not. I propose putting the true path into req.path as a string, and using a (JavaScript) helper function to split it into components instead. Alternatively the empty string '' could be appended to the list for paths ending in '/', but I think this is probably more confusing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-183) No pagination in Futon for reduce views
[ https://issues.apache.org/jira/browse/COUCHDB-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-183: - Attachment: futon_reduce_pagination.3.diff Updated patch to fetch rows_per_page + 1 rows so that the next/prev links can be enabled/disabled appropriately. This is done for both reduce and non-reduce views as we can't tell which they are until the response is returned. No pagination in Futon for reduce views --- Key: COUCHDB-183 URL: https://issues.apache.org/jira/browse/COUCHDB-183 Project: CouchDB Issue Type: Bug Components: Administration Console Affects Versions: 0.9 Reporter: Jason Davies Assignee: Christopher Lenz Priority: Blocker Fix For: 0.9 Attachments: futon_reduce_pagination.2.diff, futon_reduce_pagination.3.diff, futon_reduce_pagination.diff Futon doesn't support paginating of reduce views at the moment, which can be confusing for new users. This is due to the difficulty of efficiently working out the total number of rows available from a reduce view. I propose displaying something like Showing x-y rows of unknown at the bottom, and showing a next/previous link if there are more results to be displayed. An efficient way to calculate whether there are next/previous results would be to fetch 1 + rows_per_page + 1 (with appropriate offset parameter etc.) I did start working on a patch - will post it here when it is done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Attachment: multikey_reduce_validate.diff Minor patch to add validation for multi-key reduce _list views i.e. they should return a 500 error when group=false. _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Priority: Blocker Fix For: 0.9 Attachments: list_multikey.2.diff, list_multikey.3.diff, list_multikey.diff, multikey_reduce_validate.diff Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-283) Query parse errors should be returned as 400 Bad Request, not 500 Internal Server Error
Query parse errors should be returned as 400 Bad Request, not 500 Internal Server Error --- Key: COUCHDB-283 URL: https://issues.apache.org/jira/browse/COUCHDB-283 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Fix For: 0.9 Thus quoth Jan: jan: jasondavies: the 500 status code is for bugs in the server Patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-283) Query parse errors should be returned as 400 Bad Request, not 500 Internal Server Error
[ https://issues.apache.org/jira/browse/COUCHDB-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-283: - Attachment: bad_requests.diff This patch updates tests and couch_httpd_view:parse_view_query to throw bad_request instead of query_parse_error, thus returning a 400 instead of a 500 response. This patch also includes a minor update to couch_httpd_show to validate the query for reduce _lists (this was originally attached to COUCHDB-269, but moving it here as the tests for it also needed updating and it's only a few lines long). Query parse errors should be returned as 400 Bad Request, not 500 Internal Server Error --- Key: COUCHDB-283 URL: https://issues.apache.org/jira/browse/COUCHDB-283 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Fix For: 0.9 Attachments: bad_requests.diff Thus quoth Jan: jan: jasondavies: the 500 status code is for bugs in the server Patch to follow... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Attachment: (was: multikey_reduce_validate.diff) _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Priority: Blocker Fix For: 0.9 Attachments: list_multikey.2.diff, list_multikey.3.diff, list_multikey.diff Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Fix Version/s: 0.9 Priority: Blocker (was: Major) Marked this as blocker for 0.9. _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Priority: Blocker Fix For: 0.9 Attachments: list_multikey.2.diff, list_multikey.3.diff, list_multikey.diff Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Attachment: (was: list_multikey.2.diff) _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: list_multikey.2.diff, list_multikey.diff Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Attachment: list_multikey.3.diff Refactored start and row functions out to reduce code duplication. _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: list_multikey.2.diff, list_multikey.3.diff, list_multikey.diff Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-269) _list doesn't allow POST requests
_list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Attachment: list_multikey.diff Patch for enabling multi-key POST requests for _list. Still needs tests before committing, but posting here now in case someone needs it. _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Attachment: (was: list_multikey.diff) _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-269) _list doesn't allow POST requests
[ https://issues.apache.org/jira/browse/COUCHDB-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-269: - Comment: was deleted _list doesn't allow POST requests - Key: COUCHDB-269 URL: https://issues.apache.org/jira/browse/COUCHDB-269 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Attachments: list_multikey.diff Currently, a 405 response is returned if you issue a POST request to _list. We should allow POST requests so we can do a multi-key fetch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-260) Support for reduce views in _list
[ https://issues.apache.org/jira/browse/COUCHDB-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-260: - Attachment: list_reduce_views.3.diff Added fix and tests for bug when _list is empty (i.e. head, row and tail are ). Also started refactoring map and reduce code to remove code duplication. Support for reduce views in _list - Key: COUCHDB-260 URL: https://issues.apache.org/jira/browse/COUCHDB-260 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Priority: Blocker Fix For: 0.9 Attachments: list_reduce_views.2.diff, list_reduce_views.3.diff, list_reduce_views.diff The awesomeness of _list needs the awesomeness of reduce views. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-260) Support for reduce views in _list
[
https://issues.apache.org/jira/browse/COUCHDB-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-260:
-
Attachment: list_reduce_views.2.diff
Updated patch with fix for handling {stop: true} (thanks, Paul Davis) and more
tests.
Support for reduce views in _list
-
Key: COUCHDB-260
URL: https://issues.apache.org/jira/browse/COUCHDB-260
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Priority: Blocker
Fix For: 0.9
Attachments: list_reduce_views.2.diff, list_reduce_views.diff
The awesomeness of _list needs the awesomeness of reduce views. Patch to
follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-260) Support for reduce views in _list
[ https://issues.apache.org/jira/browse/COUCHDB-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-260: - Attachment: list_reduce_views.diff Initial patch for reduce views support for _list. Note: the map and reduce stuff does need refactoring as I noticed there's a fair bit of duplication going on. Might submit another patch for the refactoring at some point if I get time, but this does the job (TM) for now. Support for reduce views in _list - Key: COUCHDB-260 URL: https://issues.apache.org/jira/browse/COUCHDB-260 Project: CouchDB Issue Type: Bug Components: HTTP Interface Reporter: Jason Davies Priority: Blocker Fix For: 0.9 Attachments: list_reduce_views.diff The awesomeness of _list needs the awesomeness of reduce views. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-197) Replication renders CouchDB unresponsive.
[
https://issues.apache.org/jira/browse/COUCHDB-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668212#action_12668212
]
Jason Davies commented on COUCHDB-197:
--
Re: using an nginx SSL proxy: the redirection does work fine if you use
proxy_pass http://backend; instead of proxy_pass http://backend/;
Replication renders CouchDB unresponsive.
-
Key: COUCHDB-197
URL: https://issues.apache.org/jira/browse/COUCHDB-197
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.9
Reporter: Maximillian Dornseif
Priority: Blocker
Fix For: 0.9
Attachments: couch_redirects.2.diff, couch_redirects.3.diff,
couch_redirects.diff, couch_tests.js.diff, ibrowse.diff,
push_replication_fix.diff
I am quite sure this is not the same issue as in COUCHDB-193.
Im trying to replicte a somewhat big database
{doc_count:541394,doc_del_count:265692,update_seq:2118390,purge_seq:0,compact_running:false,disk_size:16552608803}
to an other machine.
I started replication with this:
send: 'POST /_replicate HTTP/1.1\r\nHost:
couchdb1.local.xxx:5984\r\nAccept-Encoding: identity\r\ncontent-length:
90\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
send: '{source: hulog_events, target:
http://couchdb2.local.xxx:5984/hulog_events}'
reply: ''
connect: (couchdb1.local.hudora.biz, 5984)
send: 'POST /_replicate HTTP/1.1\r\nHost:
couchdb1.local.:5984\r\nAccept-Encoding: identity\r\ncontent-length:
90\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
send: '{source: hulog_events, target:
http://couchdb2.local.:5984/hulog_events}'
(no reply so far)
On the source server (couchdb1) I see following logentries:
Mon, 05 Jan 2009 19:34:21 GMT] [info] [0.12745.45] 192.168.0.30 - - 'POST'
/_replicate 200
[Mon, 05 Jan 2009 19:35:36 GMT] [info] [0.107.0] Compaction for db
hulog_events_test completed.
[Mon, 05 Jan 2009 19:35:45 GMT] [info] [0.12746.45] 127.0.0.1 - - 'GET'
/hulog_events/ 200
[Mon, 05 Jan 2009 19:35:46 GMT] [info] [0.95.0] Compaction for db eap
completed.
[Mon, 05 Jan 2009 19:42:17 GMT] [error] [0.12765.45] ** Generic server
0.12765.45 terminating
** Last message in was {'EXIT',0.12762.45,
{timeout,
{gen_server,call,
[0.12768.45,
{write,
0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,2,
109,0,0,0,7,112,114,111,100,117,99,116,109,
0,0,0,8,54,53,49,52,48,47,69,75,104,2,109,0,
0,0,11,116,114,97,110,115,97,99,116,105,111,
110,109,0,0,0,8,114,101,116,114,105,101,118,
101,104,2,109,0,0,0,4,116,121,112,101,109,0,
0,0,4,117,110,105,116,104,2,109,0,0,0,11,97,
114,99,104,105,118,101,100,95,97,116,109,0,
0,0,22,50,48,48,56,48,50,50,50,84,49,50,49,
52,48,53,46,53,50,54,51,56,52,104,2,109,0,0,
0,10,99,114,101,97,116,101,100,95,97,116,
109,0,0,0,22,50,48,48,55,49,49,50,56,84,49,
53,52,50,48,54,46,51,52,52,54,49,56,104,2,
109,0,0,0,4,112,114,111,112,104,1,108,0,0,0,
2,104,2,109,0,0,0,8,108,111,99,97,116,105,
111,110,109,0,0,0,6,65,85,83,76,65,71,104,2,
109,0,0,0,6,104,101,105,103,104,116,98,0,0,
7,158,106,104,2,109,0,0,0,3,109,117,105,109,
0,0,0,18,51,52,48,48,53,57,57,56,49,48,48,
48,48,51,49,50,53,50,104,2,109,0,0,0,8,113,
117,97,110,116,105,116,121,97,11,106,106}]}}}
** When Server state == {file_descriptor,prim_file,{#Port0.904761,24}}
** Reason for termination ==
** {timeout,{gen_server,call,
[0.12768.45,
{write,0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,
2,109,0,0,0,7,112,114,111,100,117,99,116,
109,0,0,0,8,54,53,49,52,48,47,69,75,104,
2,109,0,0,0,11,116,114,97,110,115,97,99,
116,105,111,110,109,0,0,0,8,114,101,116,
114,105,101,118,101,104,2,109,0,0,0,4,
116,121,112,101,109,0,0,0,4,117,110,105,
[jira] Updated: (COUCHDB-197) Replication renders CouchDB unresponsive.
[
https://issues.apache.org/jira/browse/COUCHDB-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-197:
-
Attachment: ibrowse.diff
This patch integrates ibrowse 1.4.1 (from
http://sourceforge.net/cvs/?group_id=73688) with couch_rep.erl. It mostly
seems to have cleaned up my strange problems, although I do still get
occasional connection_closed errors.
I've made it retry requests up to 10 times if errors are encountered, and I've
limited this to GET requests on Adam Kocoloski's suggestion.
This patch also includes my couch_redirects.3 patch.
Apparently ibrowse is dual-licensed under LGPL and BSD so I think it's safe...
Replication renders CouchDB unresponsive.
-
Key: COUCHDB-197
URL: https://issues.apache.org/jira/browse/COUCHDB-197
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.9
Reporter: Maximillian Dornseif
Priority: Blocker
Fix For: 0.9
Attachments: couch_redirects.2.diff, couch_redirects.3.diff,
couch_redirects.diff, couch_tests.js.diff, ibrowse.diff,
push_replication_fix.diff
I am quite sure this is not the same issue as in COUCHDB-193.
Im trying to replicte a somewhat big database
{doc_count:541394,doc_del_count:265692,update_seq:2118390,purge_seq:0,compact_running:false,disk_size:16552608803}
to an other machine.
I started replication with this:
send: 'POST /_replicate HTTP/1.1\r\nHost:
couchdb1.local.xxx:5984\r\nAccept-Encoding: identity\r\ncontent-length:
90\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
send: '{source: hulog_events, target:
http://couchdb2.local.xxx:5984/hulog_events}'
reply: ''
connect: (couchdb1.local.hudora.biz, 5984)
send: 'POST /_replicate HTTP/1.1\r\nHost:
couchdb1.local.:5984\r\nAccept-Encoding: identity\r\ncontent-length:
90\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
send: '{source: hulog_events, target:
http://couchdb2.local.:5984/hulog_events}'
(no reply so far)
On the source server (couchdb1) I see following logentries:
Mon, 05 Jan 2009 19:34:21 GMT] [info] [0.12745.45] 192.168.0.30 - - 'POST'
/_replicate 200
[Mon, 05 Jan 2009 19:35:36 GMT] [info] [0.107.0] Compaction for db
hulog_events_test completed.
[Mon, 05 Jan 2009 19:35:45 GMT] [info] [0.12746.45] 127.0.0.1 - - 'GET'
/hulog_events/ 200
[Mon, 05 Jan 2009 19:35:46 GMT] [info] [0.95.0] Compaction for db eap
completed.
[Mon, 05 Jan 2009 19:42:17 GMT] [error] [0.12765.45] ** Generic server
0.12765.45 terminating
** Last message in was {'EXIT',0.12762.45,
{timeout,
{gen_server,call,
[0.12768.45,
{write,
0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,2,
109,0,0,0,7,112,114,111,100,117,99,116,109,
0,0,0,8,54,53,49,52,48,47,69,75,104,2,109,0,
0,0,11,116,114,97,110,115,97,99,116,105,111,
110,109,0,0,0,8,114,101,116,114,105,101,118,
101,104,2,109,0,0,0,4,116,121,112,101,109,0,
0,0,4,117,110,105,116,104,2,109,0,0,0,11,97,
114,99,104,105,118,101,100,95,97,116,109,0,
0,0,22,50,48,48,56,48,50,50,50,84,49,50,49,
52,48,53,46,53,50,54,51,56,52,104,2,109,0,0,
0,10,99,114,101,97,116,101,100,95,97,116,
109,0,0,0,22,50,48,48,55,49,49,50,56,84,49,
53,52,50,48,54,46,51,52,52,54,49,56,104,2,
109,0,0,0,4,112,114,111,112,104,1,108,0,0,0,
2,104,2,109,0,0,0,8,108,111,99,97,116,105,
111,110,109,0,0,0,6,65,85,83,76,65,71,104,2,
109,0,0,0,6,104,101,105,103,104,116,98,0,0,
7,158,106,104,2,109,0,0,0,3,109,117,105,109,
0,0,0,18,51,52,48,48,53,57,57,56,49,48,48,
48,48,51,49,50,53,50,104,2,109,0,0,0,8,113,
117,97,110,116,105,116,121,97,11,106,106}]}}}
** When Server state == {file_descriptor,prim_file,{#Port0.904761,24}}
** Reason for termination ==
** {timeout,{gen_server,call,
[0.12768.45,
{write,0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,
2,109,0,0,0,7,112,114,111,100,117,99,116,
[jira] Updated: (COUCHDB-197) Replication renders CouchDB unresponsive.
[
https://issues.apache.org/jira/browse/COUCHDB-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-197:
-
Attachment: couch_redirects.3.diff
Slightly tweaked patch: better naming and removed compiler warning about unused
variable.
Replication renders CouchDB unresponsive.
-
Key: COUCHDB-197
URL: https://issues.apache.org/jira/browse/COUCHDB-197
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.9
Reporter: Maximillian Dornseif
Priority: Blocker
Fix For: 0.9
Attachments: couch_redirects.2.diff, couch_redirects.3.diff,
couch_redirects.diff, couch_tests.js.diff, push_replication_fix.diff
I am quite sure this is not the same issue as in COUCHDB-193.
Im trying to replicte a somewhat big database
{doc_count:541394,doc_del_count:265692,update_seq:2118390,purge_seq:0,compact_running:false,disk_size:16552608803}
to an other machine.
I started replication with this:
send: 'POST /_replicate HTTP/1.1\r\nHost:
couchdb1.local.xxx:5984\r\nAccept-Encoding: identity\r\ncontent-length:
90\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
send: '{source: hulog_events, target:
http://couchdb2.local.xxx:5984/hulog_events}'
reply: ''
connect: (couchdb1.local.hudora.biz, 5984)
send: 'POST /_replicate HTTP/1.1\r\nHost:
couchdb1.local.:5984\r\nAccept-Encoding: identity\r\ncontent-length:
90\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: couchdb-python 0.5dev-r127\r\n\r\n'
send: '{source: hulog_events, target:
http://couchdb2.local.:5984/hulog_events}'
(no reply so far)
On the source server (couchdb1) I see following logentries:
Mon, 05 Jan 2009 19:34:21 GMT] [info] [0.12745.45] 192.168.0.30 - - 'POST'
/_replicate 200
[Mon, 05 Jan 2009 19:35:36 GMT] [info] [0.107.0] Compaction for db
hulog_events_test completed.
[Mon, 05 Jan 2009 19:35:45 GMT] [info] [0.12746.45] 127.0.0.1 - - 'GET'
/hulog_events/ 200
[Mon, 05 Jan 2009 19:35:46 GMT] [info] [0.95.0] Compaction for db eap
completed.
[Mon, 05 Jan 2009 19:42:17 GMT] [error] [0.12765.45] ** Generic server
0.12765.45 terminating
** Last message in was {'EXIT',0.12762.45,
{timeout,
{gen_server,call,
[0.12768.45,
{write,
0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,2,
109,0,0,0,7,112,114,111,100,117,99,116,109,
0,0,0,8,54,53,49,52,48,47,69,75,104,2,109,0,
0,0,11,116,114,97,110,115,97,99,116,105,111,
110,109,0,0,0,8,114,101,116,114,105,101,118,
101,104,2,109,0,0,0,4,116,121,112,101,109,0,
0,0,4,117,110,105,116,104,2,109,0,0,0,11,97,
114,99,104,105,118,101,100,95,97,116,109,0,
0,0,22,50,48,48,56,48,50,50,50,84,49,50,49,
52,48,53,46,53,50,54,51,56,52,104,2,109,0,0,
0,10,99,114,101,97,116,101,100,95,97,116,
109,0,0,0,22,50,48,48,55,49,49,50,56,84,49,
53,52,50,48,54,46,51,52,52,54,49,56,104,2,
109,0,0,0,4,112,114,111,112,104,1,108,0,0,0,
2,104,2,109,0,0,0,8,108,111,99,97,116,105,
111,110,109,0,0,0,6,65,85,83,76,65,71,104,2,
109,0,0,0,6,104,101,105,103,104,116,98,0,0,
7,158,106,104,2,109,0,0,0,3,109,117,105,109,
0,0,0,18,51,52,48,48,53,57,57,56,49,48,48,
48,48,51,49,50,53,50,104,2,109,0,0,0,8,113,
117,97,110,116,105,116,121,97,11,106,106}]}}}
** When Server state == {file_descriptor,prim_file,{#Port0.904761,24}}
** Reason for termination ==
** {timeout,{gen_server,call,
[0.12768.45,
{write,0,0,1,36,131,104,2,104,1,108,0,0,0,8,104,
2,109,0,0,0,7,112,114,111,100,117,99,116,
109,0,0,0,8,54,53,49,52,48,47,69,75,104,
2,109,0,0,0,11,116,114,97,110,115,97,99,
116,105,111,110,109,0,0,0,8,114,101,116,
114,105,101,118,101,104,2,109,0,0,0,4,
116,121,112,101,109,0,0,0,4,117,110,105,
116,104,2,109,0,0,0,11,97,114,99,104,105,
