[jira] [Updated] (COUCHDB-1445) CouchDB deletes .view files if it can't open them, even if the error is emfile.
[
https://issues.apache.org/jira/browse/COUCHDB-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-1445:
---
Affects Version/s: (was: 1.2)
Fix Version/s: (was: 1.2.1)
1.2
This was fixed before the 1.2 release. It's open still because it needs a
forward-port, which I've committed myself to doing.
CouchDB deletes .view files if it can't open them, even if the error is
emfile.
-
Key: COUCHDB-1445
URL: https://issues.apache.org/jira/browse/COUCHDB-1445
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.3
Reporter: Jan Lehnardt
Assignee: Randall Leeds
Priority: Blocker
Fix For: 1.1.2, 1.2, 1.3
Via Stefan Kögl on dev@:
Another thing I noticed during my tests of CouchDB 1.2.x. I redirected
live traffic to the instance and after a rather short time, requests
were failing with the following information in the logs:
[Sun, 18 Mar 2012 16:39:24 GMT] [error] [0.27554.2]
{error_report,0.31.0,
{0.27554.2,std_error,
[{application,mochiweb},
Accept failed error,
{error,emfile}]}}
[Sun, 18 Mar 2012 16:39:24 GMT] [error] [0.27554.2]
{error_report,0.31.0,
{0.27554.2,crash_report,
[[{initial_call,
{mochiweb_acceptor,init,
['Argument__1','Argument__2',
'Argument__3']}},
{pid,0.27554.2},
{registered_name,[]},
{error_info,
{exit,
{error,accept_failed},
[{mochiweb_acceptor,init,3},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_httpd,couch_secondary_services,
couch_server_sup,0.32.0]},
{messages,[]},
{links,[0.129.0]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,233},
{stack_size,24},
{reductions,244}],
[]]}}
I think emfile means that CouchDB (or mochiweb?) couldn't open any
more files / connections. I've set the (hard and soft) nofile limit for
user couchdb to 4096, but didn't raise the ERL_MAX_PORTS accordingly.
Anyway, as soon as the error occured, CouchDB started writing most of my
view files from scratch, rendering the instance unusable.
I'd expect CouchDB to fail more gracefully when the maximum number of
open files is reached. Is this a bug or expected behaviour?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1445) CouchDB deletes .view files if it can't open them, even if the error is emfile.
[
https://issues.apache.org/jira/browse/COUCHDB-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-1445:
---
Priority: Blocker (was: Major)
Affects Version/s: 1.3
1.1.1
Fix Version/s: 1.3
Fixed on 1.1.x and 1.2.x. Blocking master for 1.3.
To https://git-wip-us.apache.org/repos/asf/couchdb.git
29eac04..94e72e7 1.2.x - 1.2.x
785d32f..24a61fd 1.1.x - 1.1.x
CouchDB deletes .view files if it can't open them, even if the error is
emfile.
-
Key: COUCHDB-1445
URL: https://issues.apache.org/jira/browse/COUCHDB-1445
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Jan Lehnardt
Assignee: Randall Leeds
Priority: Blocker
Fix For: 1.2, 1.3, 1.1.2
Via Stefan Kögl on dev@:
Another thing I noticed during my tests of CouchDB 1.2.x. I redirected
live traffic to the instance and after a rather short time, requests
were failing with the following information in the logs:
[Sun, 18 Mar 2012 16:39:24 GMT] [error] [0.27554.2]
{error_report,0.31.0,
{0.27554.2,std_error,
[{application,mochiweb},
Accept failed error,
{error,emfile}]}}
[Sun, 18 Mar 2012 16:39:24 GMT] [error] [0.27554.2]
{error_report,0.31.0,
{0.27554.2,crash_report,
[[{initial_call,
{mochiweb_acceptor,init,
['Argument__1','Argument__2',
'Argument__3']}},
{pid,0.27554.2},
{registered_name,[]},
{error_info,
{exit,
{error,accept_failed},
[{mochiweb_acceptor,init,3},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_httpd,couch_secondary_services,
couch_server_sup,0.32.0]},
{messages,[]},
{links,[0.129.0]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,233},
{stack_size,24},
{reductions,244}],
[]]}}
I think emfile means that CouchDB (or mochiweb?) couldn't open any
more files / connections. I've set the (hard and soft) nofile limit for
user couchdb to 4096, but didn't raise the ERL_MAX_PORTS accordingly.
Anyway, as soon as the error occured, CouchDB started writing most of my
view files from scratch, rendering the instance unusable.
I'd expect CouchDB to fail more gracefully when the maximum number of
open files is reached. Is this a bug or expected behaviour?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-687) Add md5 hash to _attachments properties for documents
[
https://issues.apache.org/jira/browse/COUCHDB-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-687:
--
Fix Version/s: 1.3
2.0
Add md5 hash to _attachments properties for documents
-
Key: COUCHDB-687
URL: https://issues.apache.org/jira/browse/COUCHDB-687
Project: CouchDB
Issue Type: Improvement
Environment: CouchDB
Reporter: mikeal
Assignee: Filipe Manana
Fix For: 2.0, 1.3
Attachments: couchdb-md5-in-attachment-COUCHDB-687-v2.patch,
couchdb-md5-in-attachment-COUCHDB-687-v3.patch,
couchdb-md5-in-attachment-COUCHDB-687.patch, md5.patch
The current attachment information looks like this:
GET /dbname/docid
_attachments: {
jquery-1.4.1.min.js: {
content_type: text/javascript
revpos: 138
length: 70844
stub: true
}
}
If a client wanted to sync local files as attachments with a document it
would not currently be able to do so without keeping a local store of the
revpos. If this information included an md5 hash of the attachment clients
could compare it against a hash of the local file to see if they match.
-Mikeal
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-111) Javascript Error Tracebacks
[ https://issues.apache.org/jira/browse/COUCHDB-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-111: -- Attachment: v4-0003-COUCHDB-111-CommonJS-module-names-in-tracebacks.patch Patch adds filename information to CommonJS module calls in stack traces. Javascript Error Tracebacks --- Key: COUCHDB-111 URL: https://issues.apache.org/jira/browse/COUCHDB-111 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Paul Joseph Davis Assignee: Chris Anderson Attachments: v1-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v1-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v2-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v2-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v3-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v3-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v4-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v4-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v4-0003-COUCHDB-111-CommonJS-module-names-in-tracebacks.patch Improve the errors reported by the javascript view server to provide a more friendly error report when something goes wrong. Ideally a complete traceback but anything would be better than the erlang traceback informing the user that the server died. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1377) support X-Forwarded-* headers in couch_httpd
[ https://issues.apache.org/jira/browse/COUCHDB-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1377: --- Attachment: v1-0001-COUCHDB-1377-X-Forwarded-headers-in-proxy-module.patch support X-Forwarded-* headers in couch_httpd Key: COUCHDB-1377 URL: https://issues.apache.org/jira/browse/COUCHDB-1377 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 1.1.1, 1.2 Reporter: Randall Leeds Assignee: Randall Leeds Fix For: 1.2.1, 1.3 Attachments: v1-0001-COUCHDB-1377-X-Forwarded-headers-in-proxy-module.patch X-Forwarded-For, as well as X-Forwarded-Proto and X-Forwarded-Ssl, are partially supported by the couch_httpd module. However, the couch_httpd_proxy module ignores these same configuration settings when it could manipulate the headers to pass more information upstream. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1338) JS CLI test suite: have CouchDB start with port=0
[ https://issues.apache.org/jira/browse/COUCHDB-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1338: --- Attachment: v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch JS CLI test suite: have CouchDB start with port=0 -- Key: COUCHDB-1338 URL: https://issues.apache.org/jira/browse/COUCHDB-1338 Project: CouchDB Issue Type: Improvement Components: Test Suite Affects Versions: 1.3 Reporter: Jan Lehnardt Assignee: Randall Leeds Priority: Blocker Fix For: 1.3 Attachments: v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch, v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch The JS CLI test suite that now runs with make check (post 1.2.x master only) starts CouchDB using make dev utils/run -b and stops it with utils/run -d. One issue with this is that one might have CouchDB already running on the default port 5984. The suggestion here is to start CouchDB with an additional .ini file that sets the port number to 0 to let the TCP stack figure out a free port for us. The tests then need to be updated to discover the automatic port using the couch.uri file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1338) JS CLI test suite: have CouchDB start with port=0
[ https://issues.apache.org/jira/browse/COUCHDB-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1338: --- Attachment: (was: v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch) JS CLI test suite: have CouchDB start with port=0 -- Key: COUCHDB-1338 URL: https://issues.apache.org/jira/browse/COUCHDB-1338 Project: CouchDB Issue Type: Improvement Components: Test Suite Affects Versions: 1.3 Reporter: Jan Lehnardt Assignee: Randall Leeds Priority: Blocker Fix For: 1.3 Attachments: v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch, v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch The JS CLI test suite that now runs with make check (post 1.2.x master only) starts CouchDB using make dev utils/run -b and stops it with utils/run -d. One issue with this is that one might have CouchDB already running on the default port 5984. The suggestion here is to start CouchDB with an additional .ini file that sets the port number to 0 to let the TCP stack figure out a free port for us. The tests then need to be updated to discover the automatic port using the couch.uri file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1338) JS CLI test suite: have CouchDB start with port=0
[ https://issues.apache.org/jira/browse/COUCHDB-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1338: --- Attachment: (was: v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch) JS CLI test suite: have CouchDB start with port=0 -- Key: COUCHDB-1338 URL: https://issues.apache.org/jira/browse/COUCHDB-1338 Project: CouchDB Issue Type: Improvement Components: Test Suite Affects Versions: 1.3 Reporter: Jan Lehnardt Assignee: Randall Leeds Priority: Blocker Fix For: 1.3 Attachments: v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch, v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch The JS CLI test suite that now runs with make check (post 1.2.x master only) starts CouchDB using make dev utils/run -b and stops it with utils/run -d. One issue with this is that one might have CouchDB already running on the default port 5984. The suggestion here is to start CouchDB with an additional .ini file that sets the port number to 0 to let the TCP stack figure out a free port for us. The tests then need to be updated to discover the automatic port using the couch.uri file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1338) JS CLI test suite: have CouchDB start with port=0
[ https://issues.apache.org/jira/browse/COUCHDB-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1338: --- Attachment: v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch JS CLI test suite: have CouchDB start with port=0 -- Key: COUCHDB-1338 URL: https://issues.apache.org/jira/browse/COUCHDB-1338 Project: CouchDB Issue Type: Improvement Components: Test Suite Affects Versions: 1.3 Reporter: Jan Lehnardt Assignee: Randall Leeds Priority: Blocker Fix For: 1.3 Attachments: v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch, v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch The JS CLI test suite that now runs with make check (post 1.2.x master only) starts CouchDB using make dev utils/run -b and stops it with utils/run -d. One issue with this is that one might have CouchDB already running on the default port 5984. The suggestion here is to start CouchDB with an additional .ini file that sets the port number to 0 to let the TCP stack figure out a free port for us. The tests then need to be updated to discover the automatic port using the couch.uri file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-111) Javascript Error Tracebacks
[ https://issues.apache.org/jira/browse/COUCHDB-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-111: -- Attachment: v1-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch v1-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch Javascript Error Tracebacks --- Key: COUCHDB-111 URL: https://issues.apache.org/jira/browse/COUCHDB-111 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Paul Joseph Davis Assignee: Chris Anderson Attachments: v1-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v1-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch Improve the errors reported by the javascript view server to provide a more friendly error report when something goes wrong. Ideally a complete traceback but anything would be better than the erlang traceback informing the user that the server died. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-111) Javascript Error Tracebacks
[ https://issues.apache.org/jira/browse/COUCHDB-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-111: -- Attachment: v2-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch v2-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch Javascript Error Tracebacks --- Key: COUCHDB-111 URL: https://issues.apache.org/jira/browse/COUCHDB-111 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Paul Joseph Davis Assignee: Chris Anderson Attachments: v1-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v1-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v2-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v2-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch Improve the errors reported by the javascript view server to provide a more friendly error report when something goes wrong. Ideally a complete traceback but anything would be better than the erlang traceback informing the user that the server died. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-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
]
Randall Leeds updated COUCHDB-410:
--
Attachment: v1-0001-COUCHDB-410-graceful-validate_doc_update-errors.patch
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: 1.3
Attachments: util.js.diff,
v1-0001-COUCHDB-410-graceful-validate_doc_update-errors.patch
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).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-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
]
Randall Leeds updated COUCHDB-410:
--
Attachment: v2-0001-COUCHDB-410-graceful-validate_doc_update-errors.patch
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: 1.3
Attachments: util.js.diff,
v1-0001-COUCHDB-410-graceful-validate_doc_update-errors.patch,
v2-0001-COUCHDB-410-graceful-validate_doc_update-errors.patch
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).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-111) Javascript Error Tracebacks
[ https://issues.apache.org/jira/browse/COUCHDB-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-111: -- Attachment: v3-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch v3-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch Javascript Error Tracebacks --- Key: COUCHDB-111 URL: https://issues.apache.org/jira/browse/COUCHDB-111 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Paul Joseph Davis Assignee: Chris Anderson Attachments: v1-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v1-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v2-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v2-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v3-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v3-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch Improve the errors reported by the javascript view server to provide a more friendly error report when something goes wrong. Ideally a complete traceback but anything would be better than the erlang traceback informing the user that the server died. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1338) JS CLI test suite: have CouchDB start with port=0
[ https://issues.apache.org/jira/browse/COUCHDB-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1338: --- Attachment: v2-0002-Fix-JS-tests-for-COUCHDB-1338.patch v2-0001-COUCHDB-1338-run-js-tests-with-port-0.patch JS CLI test suite: have CouchDB start with port=0 -- Key: COUCHDB-1338 URL: https://issues.apache.org/jira/browse/COUCHDB-1338 Project: CouchDB Issue Type: Improvement Components: Test Suite Affects Versions: 1.3 Reporter: Jan Lehnardt Assignee: Randall Leeds Priority: Blocker Fix For: 1.3 Attachments: v1-0001-COUCHDB-1338-run-js-tests-with-port-0.patch, v1-0002-Fix-JS-tests-for-COUCHDB-1338.patch, v2-0001-COUCHDB-1338-run-js-tests-with-port-0.patch, v2-0002-Fix-JS-tests-for-COUCHDB-1338.patch The JS CLI test suite that now runs with make check (post 1.2.x master only) starts CouchDB using make dev utils/run -b and stops it with utils/run -d. One issue with this is that one might have CouchDB already running on the default port 5984. The suggestion here is to start CouchDB with an additional .ini file that sets the port number to 0 to let the TCP stack figure out a free port for us. The tests then need to be updated to discover the automatic port using the couch.uri file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-111) Javascript Error Tracebacks
[ https://issues.apache.org/jira/browse/COUCHDB-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-111: -- Attachment: v4-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch v4-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch Javascript Error Tracebacks --- Key: COUCHDB-111 URL: https://issues.apache.org/jira/browse/COUCHDB-111 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Paul Joseph Davis Assignee: Chris Anderson Attachments: v1-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v1-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v2-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v2-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v3-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v3-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch, v4-0001-COUCHDB-111-handle-multiple-files-in-couchjs.patch, v4-0002-COUCHDB-111-JavaScript-Error-Tracebacks.patch Improve the errors reported by the javascript view server to provide a more friendly error report when something goes wrong. Ideally a complete traceback but anything would be better than the erlang traceback informing the user that the server died. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1376) enable JaegerMonkey features
[ https://issues.apache.org/jira/browse/COUCHDB-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1376: --- Attachment: v1-0001-COUCHDB-1376-enable-JaegerMonkey-features.patch enable JaegerMonkey features Key: COUCHDB-1376 URL: https://issues.apache.org/jira/browse/COUCHDB-1376 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Randall Leeds Assignee: Randall Leeds Priority: Minor Fix For: 1.3 Attachments: v1-0001-COUCHDB-1376-enable-JaegerMonkey-features.patch In recent versions of SpiderMonkey, the method JIT (sometimes referred to as JaegerMonkey) is considered stable for use and ships on by default in Firefox builds. Newer, unreleased, upstream versions also have type inference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1367) update_seq does not always reflect the seq of the latest document update
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1367: --- Description: Certain operations, (currently _revs_limit and _security changes) cause the database header's update_seq to increase when the by_seq index (and therefore _changes) has not changed, which is confusing in light of the naming consistency. (was: If you put a number to _revs_limit on a db (to update it) - the http://host/dbname/ info document gets an increase in update_seq number - however the changes feed does not contain this change (while its not a change). This causes the update_seq in the dbinfo doc and the last seq in the changes feed to differ - which breaks any application depending on the update_seq number as the expected sequence size of the db (in my case - couchdb-lucene that will only respond to stale requests because it thinks its not up to date) I know this is an edge case - but still its something fairly fundamental - that clearly is not working as intended. ) Summary: update_seq does not always reflect the seq of the latest document update (was: When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes) Updated the description and title to reflect the problem in general. Proposals so far: 1. Add a new header field a. to track the highest value in the by_seq index b. to track header updates that do not affect by_seq, causing update_seq to behave in a manner more consistent with expectation 2. Migrate the non-replicable metadata into the document API and hang it within the by_seq index As far as I can tell I'm the only proponent of (2). Proposal (2) is broader in scope, more difficult to implement, and fails to account for the possibility that other, current or future, database header updates may not fit into the document model. Therefore, I'll formally retract my suggestion that it be pursued as a solution to the present ticket. Resuming discussion back here (sorry if it was unnecessary or confusing that I migrated it to dev@), how does the community feel about (1a) vs (1b)? I'm in favor of 1b, myself. update_seq does not always reflect the seq of the latest document update Key: COUCHDB-1367 URL: https://issues.apache.org/jira/browse/COUCHDB-1367 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.1.1 Environment: Any Reporter: Henrik Hofmeister Priority: Minor Labels: revs_limit Certain operations, (currently _revs_limit and _security changes) cause the database header's update_seq to increase when the by_seq index (and therefore _changes) has not changed, which is confusing in light of the naming consistency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1371) configure erroneously warns against using a new spidermonkey with old spidermonkeys
[ https://issues.apache.org/jira/browse/COUCHDB-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1371: --- Attachment: 0001-fix-bad-configure-warning-on-old-SpiderMonkey.patch Here's a patch which fixes this. I'd like to apply it. Though, on a related note, I'd be glad to drop support for 1.7 spidermonkey since the INSTALL files have already been updated to say = 1.8. configure erroneously warns against using a new spidermonkey with old spidermonkeys --- Key: COUCHDB-1371 URL: https://issues.apache.org/jira/browse/COUCHDB-1371 Project: CouchDB Issue Type: Bug Reporter: Randall Leeds Assignee: Randall Leeds Priority: Minor Fix For: 1.2, 1.3, 1.1.2 Attachments: 0001-fix-bad-configure-warning-on-old-SpiderMonkey.patch Paul added the check for JSOPTION_ANONFUNFIX in 7ce9e103e, but js-1.7 doesn't have this constant so configure gives a warning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1293) Support in memory databases that can replicate
[ https://issues.apache.org/jira/browse/COUCHDB-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1293: --- Skill Level: Committers Level (Medium to Hard) Issue Type: Wish (was: New Feature) Marking as a Wish and leaving it open with no fix version. Alternate implementations are really hard to put into the code base right now since so much calls directly into couch_btree and couch_btree calls directly into couch_file. It'd be neat to see it done but it's not a blocker for anything afaik. Support in memory databases that can replicate -- Key: COUCHDB-1293 URL: https://issues.apache.org/jira/browse/COUCHDB-1293 Project: CouchDB Issue Type: Wish Reporter: Sam Bisbee The summary really says it all. It would be great if we could have databases that live only in memory, but that could also be replicated to other URLs (potentially a database on disk or another node in a cluster). I don't think views would be necessary for the sorts of things you'd be doing all in memory (session data, temp data, etc.). I talked with Kocoloski about this around a month ago and it did not sound like an easy feat because of the replication. I would still like to hear what people have to say about it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1363) callback invocation for docs added during couch_changes startup can be delayed by race condition
[ https://issues.apache.org/jira/browse/COUCHDB-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1363: --- Description: After subscribing to notifications it's necessary to re-open the #db a so that the header points at all updates for which the updater notifier has already fired events. In practice, this is rarely problematic because the next change will cause everything to catch up, but if a quick burst of changes happens while, e.g., replication is starting the replication can go stale. Detected by intermittent replicator_db js test failures. (was: It's necessary to re-open the #db after subscribing to notifications so that updates are not lost. In practice, this is rarely problematic because the next change will cause everything to catch up, but if a quick burst of changes happens while replication is starting the replication can go stale. Detected by intermittent replicator_db js test failures.) Summary: callback invocation for docs added during couch_changes startup can be delayed by race condition (was: Race condition edge case when pulling local changes) callback invocation for docs added during couch_changes startup can be delayed by race condition Key: COUCHDB-1363 URL: https://issues.apache.org/jira/browse/COUCHDB-1363 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.0.3, 1.1.1 Reporter: Randall Leeds Assignee: Filipe Manana Priority: Minor Fix For: 1.2, 1.3 Attachments: 0001-Fix-a-race-condition-starting-replications.patch After subscribing to notifications it's necessary to re-open the #db a so that the header points at all updates for which the updater notifier has already fired events. In practice, this is rarely problematic because the next change will cause everything to catch up, but if a quick burst of changes happens while, e.g., replication is starting the replication can go stale. Detected by intermittent replicator_db js test failures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1363) Race condition edge case when pulling local changes
[ https://issues.apache.org/jira/browse/COUCHDB-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1363: --- Attachment: 0001-Fix-a-race-condition-starting-replications.patch Race condition edge case when pulling local changes --- Key: COUCHDB-1363 URL: https://issues.apache.org/jira/browse/COUCHDB-1363 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.0.3, 1.1.1 Reporter: Randall Leeds Priority: Minor Fix For: 1.2, 1.3 Attachments: 0001-Fix-a-race-condition-starting-replications.patch It's necessary to re-open the #db after subscribing to notifications so that updates are not lost. In practice, this is rarely problematic because the next change will cause everything to catch up, but if a quick burst of changes happens while replication is starting the replication can go stale. Detected by intermittent replicator_db js test failures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1352) couch_db does not allow custom system database names
[ https://issues.apache.org/jira/browse/COUCHDB-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1352: --- Attachment: 0001-COUCHDB-1352-allow-custom-system-database-names.patch Patch to allow custom names. Includes etap tests to ensure that user databases may not start with an underscore and that system databases may have any name (though must be more than _just_ an underscore). couch_db does not allow custom system database names Key: COUCHDB-1352 URL: https://issues.apache.org/jira/browse/COUCHDB-1352 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.3, 1.1.1 Reporter: Randall Leeds Assignee: Randall Leeds Attachments: 0001-COUCHDB-1352-allow-custom-system-database-names.patch _replicator and _users are hard coded as acceptable database names. This restriction seems to contradict the presence of config variables that change the replicator and authentication database names. Changing them causes a crash. Since the couch_db module accepts an options argument which can contain the atom 'sys_db', allow creation of such system databases with custom names. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-860) Futon appends wrong version number to files
[ https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-860: -- Attachment: 0002-Futon-Cache-Control.patch 0001-remove-version-number-from-futon-static-resources.patch Here are two patches. First one removes the version number. Second one serves futon resources with cache-control headers to help prevent issues with futon caching. Does this look right? Futon appends wrong version number to files --- Key: COUCHDB-860 URL: https://issues.apache.org/jira/browse/COUCHDB-860 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.0.1 Reporter: Volker Mische Priority: Minor Attachments: 0001-remove-version-number-from-futon-static-resources.patch, 0002-Futon-Cache-Control.patch Futon appends the CouchDB version number to the JavaScript files it loads. In 1.0.1 it still appends 0.11 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1164) Pass CouchDB version to view server
[ https://issues.apache.org/jira/browse/COUCHDB-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1164: --- Fix Version/s: 2.0 As per my comment on COUCHDB-904, 2.0 seems like a good time to do this. Pass CouchDB version to view server --- Key: COUCHDB-1164 URL: https://issues.apache.org/jira/browse/COUCHDB-1164 Project: CouchDB Issue Type: New Feature Components: JavaScript View Server Reporter: Alexander Shorin Priority: Minor Fix For: 2.0 Imagine that I'm developer of some view server. I'd like to create view server which covers most of CouchDB releases. Each new CouchDB release brings new features, improvements and API changes, some times backward-incompatible (as for 0.9-0.10-0.11-0.11.1) . However, I couldn't solve this task due to there is not way to know about CouchDB version and API that I have to implement. So there are three ways that I have: 1. develop only bleeding edge view server that support only latest version 2. make separate branch per version 3. keep all in one and pass version as command line argument. First one makes to forgot about old releases, second is supporting hell. Last one is more effective, but requires to keep in mind changing argument on server update. So there is actually no way to make great view server such as javascript/erlang one with wide CouchDB versions support. Without that support using and developing couchapps for ruby/python/clojure/others view servers is quite unpromising. This issue could be an improvement of COUCHDB-904 by using next scenario: CouchDB pass version command to view server with additional value of CouchDB version and excepts that view server return his version back. That would be something like version exchange. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-904) No method to detect view server VM version
[
https://issues.apache.org/jira/browse/COUCHDB-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-904:
--
Fix Version/s: 2.0
I'm going to say this is a good one for 2.0. Breaks protocol, but also a major
version release is a good time to install these sorts of forward-compatibility
features.
No method to detect view server VM version
--
Key: COUCHDB-904
URL: https://issues.apache.org/jira/browse/COUCHDB-904
Project: CouchDB
Issue Type: New Feature
Components: JavaScript View Server
Reporter: Paul Joseph Davis
Priority: Minor
Fix For: 2.0
Attachments: patch.txt
There's currently no way to tell what version of the view server is being
used. Ie, the JS VM (Or Python, or Ruby, etc) that is being used. Just
occurred to me it could be useful for debugging things that work one place
and not another.
A proposed simple fix would be to have the view server protocol dictate that
when a server boots up it spits out a line like:
{version: OPAQUE_STRING} that gets stored in a view_server_versions section
in the config or some such.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1136) cleanup views does not work when a database has no design documents
[ https://issues.apache.org/jira/browse/COUCHDB-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds updated COUCHDB-1136: --- Description: When a database has no design documents the cleanup code creates an empty regex which matches everything, thus saving all the index files. In this case it should delete everything instead. (was: When a view has no design documents the cleanup code creates an empty regex which matches everything, thus saving all the index files. In this case it should delete everything instead.) Summary: cleanup views does not work when a database has no design documents (was: cleanup views does not work when a design document has no views) Thanks, Adam. That's what I intended to fix, I just misunderstood the exact conditions. Updated description for posterity. cleanup views does not work when a database has no design documents --- Key: COUCHDB-1136 URL: https://issues.apache.org/jira/browse/COUCHDB-1136 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.0.2 Reporter: Randall Leeds Assignee: Randall Leeds Priority: Minor Fix For: 1.1.1, 1.2 Attachments: fix_empty_ddoc_cleanup.patch, view_cleanup_etap.patch When a database has no design documents the cleanup code creates an empty regex which matches everything, thus saving all the index files. In this case it should delete everything instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1285) Allow configuration of vendor and module version in the welcome message
[
https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-1285:
---
Attachment: vendor_and_modules.patch
I think just vendor (not plural) is sufficient and consistent with the way it
makes sense to configure.
{couchdb : WelcomeMessage,
version : ...,
vendor : {couch_config:get(vendor)}
}
This patch impements the above, takes the modules section out of the welcome
message, and uses the [modules] section as MFA tuples for secondary supervisors.
1) [modules] provides a place to OTP-ify secondary couch supervisors (I've
already done this with couch_update_notifier_sup in this patch).
2) Modules are required to be supervise-able and authors of well-behaved
modules can take care to unset any changes the module makes to couch_config if
the module is stopped (automatically done if [modules] section is changed).
3) Modules have a start-up hook so that authors need not ship a .ini file if
they would rather use couch_config from code at startup. Also, the start-up
hook can initialize modules of any complexity and ensure proper supervision.
4) Values from acinclude.m4 are placed into the default.ini template for
[vendor] so that it's possible to keep the autotools packaging and change
acinclude.m4 to have custom vendor version.
5) Module installations are not automatically made known to clients. Some
modules perhaps should not broadcast their presence and those that do should
consider doing so at a well known endpoint rather than in the welcome message.
I would suggest establishing a convention for authors to provide their own
welcome message/object under /_module/name. This path prefix can also provide
modules with a place to attach any interface (user or application). This is
only convention and no new code. Additionally, it provides a convention for
querying for module presence.
Allow configuration of vendor and module version in the welcome message
---
Key: COUCHDB-1285
URL: https://issues.apache.org/jira/browse/COUCHDB-1285
Project: CouchDB
Issue Type: Improvement
Reporter: Jan Lehnardt
Attachments: vendor_and_modules.patch,
vendor_and_modules_objects.patch
The patch below allows to configure vendor and module version information
into the GET / welcome message.
E.g.
[vendor]
name = refuge
version = 2.0.0
[modules]
geocouch = 1.2.1
would produce:
{couchdb:Welcome,version:1.2.0,refuge:2.0.0,modules:{geocouch:1.2.1}}
--
--- a/src/couchdb/couch_httpd_misc_handlers.erl
+++ b/src/couchdb/couch_httpd_misc_handlers.erl
@@ -30,9 +30,23 @@
% httpd global handlers
handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) -
+Vendor = case couch_config:get(vendor) of
+ [] - [];
+ Vendor1 - [{
+proplists:get_value(name, Vendor1),
+?l2b(proplists:get_value(version, Vendor1))
+ }]
+end,
+
+Modules = lists:map(fun({Key, Value}) -
+ {Key, ?l2b(Value)}
+end, couch_config:get(modules)),
+
send_json(Req, {[
{couchdb, WelcomeMessage},
-{version, list_to_binary(couch_server:get_version())}
+{version, list_to_binary(couch_server:get_version())}]
+++ Vendor
+++ [{modules, {Modules}}
]});
handle_welcome_req(Req, _) -
send_method_not_allowed(Req, GET,HEAD).
--
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1285) Allow configuration of vendor and module version in the welcome message
[
https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-1285:
---
Attachment: vendor_only.patch
Sure thing, Ben.
Here's a version of the patch that only does the vendor bits. I added back the
handling of an empty [vendor] section like Jan had it, just in case.
Default setup shows
{couchdb:Welcome,version:1.3.0a-0dd0168-git,vendor:{version:1.3.0a-0dd0168-git,name:The
Apache Software Foundation}}
No objections I'll commit this tomorrow.
Allow configuration of vendor and module version in the welcome message
---
Key: COUCHDB-1285
URL: https://issues.apache.org/jira/browse/COUCHDB-1285
Project: CouchDB
Issue Type: Improvement
Reporter: Jan Lehnardt
Attachments: vendor_and_modules.patch,
vendor_and_modules_objects.patch, vendor_only.patch
The patch below allows to configure vendor and module version information
into the GET / welcome message.
E.g.
[vendor]
name = refuge
version = 2.0.0
[modules]
geocouch = 1.2.1
would produce:
{couchdb:Welcome,version:1.2.0,refuge:2.0.0,modules:{geocouch:1.2.1}}
--
--- a/src/couchdb/couch_httpd_misc_handlers.erl
+++ b/src/couchdb/couch_httpd_misc_handlers.erl
@@ -30,9 +30,23 @@
% httpd global handlers
handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) -
+Vendor = case couch_config:get(vendor) of
+ [] - [];
+ Vendor1 - [{
+proplists:get_value(name, Vendor1),
+?l2b(proplists:get_value(version, Vendor1))
+ }]
+end,
+
+Modules = lists:map(fun({Key, Value}) -
+ {Key, ?l2b(Value)}
+end, couch_config:get(modules)),
+
send_json(Req, {[
{couchdb, WelcomeMessage},
-{version, list_to_binary(couch_server:get_version())}
+{version, list_to_binary(couch_server:get_version())}]
+++ Vendor
+++ [{modules, {Modules}}
]});
handle_welcome_req(Req, _) -
send_method_not_allowed(Req, GET,HEAD).
--
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-893) Error: os_process_error {exit_status,0} when rendering view on 17 mb doc, couchapp and data attached
[
https://issues.apache.org/jira/browse/COUCHDB-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-893:
--
Attachment: 0001-improve-argument-parsing-in-couchjs.patch
Patch that exposes the --stack-size option Paul made available in the
SpiderMonkey 1.8.5 work by removing the couchjs script and moving argument
parsing entirely into the couchjs binary application.
Error: os_process_error {exit_status,0} when rendering view on 17 mb doc,
couchapp and data attached
---
Key: COUCHDB-893
URL: https://issues.apache.org/jira/browse/COUCHDB-893
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.0.1
Environment: I repeated this on windows and linux (64 bit)
Reporter: Michael Schneider
Assignee: Randall Leeds
Fix For: 1.1.1, 1.2
Attachments: 0001-improve-argument-parsing-in-couchjs.patch,
bugdoc.tar.gz
I have a large set of documents that I harvesting data from. All docs 9mb
render fine (with doc size increased)
Attached is a simple couchapp and one doc.
To reproduce, untar and:
reproduce
1) untar file
2) cd bugdoc/couchapp/bugreport
3) couchapp push bugreport
4) cd bugdoc
5) python submitbadjson.py
open url
http://127.0.0.1:5984/_utils/database.html?bugreport/_design/bugreport/_view/buggy
You should see a popup
(Error: os_process_error
{exit_status,0})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-752) InternalError: script stack space quota is exhausted
[
https://issues.apache.org/jira/browse/COUCHDB-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-752:
--
Fix Version/s: 1.1.1
InternalError: script stack space quota is exhausted
Key: COUCHDB-752
URL: https://issues.apache.org/jira/browse/COUCHDB-752
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 0.11
Reporter: Benoit Chesneau
Assignee: Randall Leeds
Priority: Critical
Fix For: 1.1.1, 1.2
Attachments: ddoc.patch
Couchdb freeze and use full CPU after accessing to a 93MB designdoc:
debug] [0.91.0] Spawning new group server for view group _design/aimpl in
database aimpl.
[debug] [0.94.0] request_group {Pid, Seq} {0.116.0,61}
[debug] [0.81.0] New task status for aimpl _design/aimpl: Finishing.
[debug] [0.126.0] OS Process Start :: #Port0.2040
[debug] [0.87.0] Teach ddoc to new proc {proc,0.126.0,javascript,[],
{couch_os_process,prompt},
{couch_os_process,set_timeout},
{couch_os_process,stop}} with DDocKey:
{_design/aimpl,
30-2ab623a62b83b0d9f2616ee209f62659}
InternalError: script stack space quota is exhausted
Most of data are in attachments :
enlil:couchapp benoitc$ du -sh aimpl
93M aimpl
enlil:couchapp benoitc$ du -sh aimpl/_attachments/
93M aimpl/_attachments/
about 100k in views/shows/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-648) _update handler ignores code in response doc
[
https://issues.apache.org/jira/browse/COUCHDB-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-648:
--
Fix Version/s: 1.2
1.1.1
_update handler ignores code in response doc
--
Key: COUCHDB-648
URL: https://issues.apache.org/jira/browse/COUCHDB-648
Project: CouchDB
Issue Type: Bug
Components: Database Core
Environment: CouchDB from HEAD
Reporter: Cliff Stanford
Assignee: Randall Leeds
Labels: update
Fix For: 1.1.1, 1.2
Attachments:
0001-Document-update-handlers-now-honor-code-in-response-.patch, test.diff
When using an _update handler, it should be possible to return a response
code.
return [ doc, {
headers : { Location : / },
code : 303,
body : 'Redirecting'
}];
Should return 303 (the redirect for POST) but in fact, on a successful create
returns 201. This means it is not possible to use the browser to POST as you
cannot redirect on return. This feels like a bug.
In any case, I would respectfully suggest that the syntax of the _update
handler be changed so that there is a store(doc) call (or similar) which
returns a JSON object to the update handler so that the handler may redirect
appropriately. That would make it possible to do updates client-side with
little or no client-side javascript.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-893) Error: os_process_error {exit_status,0} when rendering view on 17 mb doc, couchapp and data attached
[
https://issues.apache.org/jira/browse/COUCHDB-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-893:
--
Fix Version/s: 1.2
1.1.1
Error: os_process_error {exit_status,0} when rendering view on 17 mb doc,
couchapp and data attached
---
Key: COUCHDB-893
URL: https://issues.apache.org/jira/browse/COUCHDB-893
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.0.1
Environment: I repeated this on windows and linux (64 bit)
Reporter: Michael Schneider
Assignee: Randall Leeds
Fix For: 1.1.1, 1.2
Attachments: bugdoc.tar.gz
I have a large set of documents that I harvesting data from. All docs 9mb
render fine (with doc size increased)
Attached is a simple couchapp and one doc.
To reproduce, untar and:
reproduce
1) untar file
2) cd bugdoc/couchapp/bugreport
3) couchapp push bugreport
4) cd bugdoc
5) python submitbadjson.py
open url
http://127.0.0.1:5984/_utils/database.html?bugreport/_design/bugreport/_view/buggy
You should see a popup
(Error: os_process_error
{exit_status,0})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
