[jira] [Commented] (COUCHDB-1436) Sometimes a newly created document does not appear in the database although operation for its creating returns ok=true
[ https://issues.apache.org/jira/browse/COUCHDB-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227575#comment-13227575 ] Marcello Nuccio commented on COUCHDB-1436: -- Isn't it the same as COUCHDB-1415 ? Sometimes a newly created document does not appear in the database although operation for its creating returns ok=true Key: COUCHDB-1436 URL: https://issues.apache.org/jira/browse/COUCHDB-1436 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 1.1 Reporter: Oleg Rostanin Sometimes after creating a document via http request a newly created document does not apper in the db (both in Web gui and when requested through API) althougho the response of the creation request returned ok=true, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[ https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201198#comment-13201198 ] Marcello Nuccio commented on COUCHDB-1397: -- @James, that's what I'm doing. I find that tests written this way are more complex with respect to tests I write for other things. But, I'm clearly missing something obvious here, since I'm alone on this. Function expressions, evals in SpiderMonkey --- Key: COUCHDB-1397 URL: https://issues.apache.org/jira/browse/COUCHDB-1397 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Affects Versions: 1.2.1 Environment: All Reporter: Jason Smith New SpiderMonkey releases do not eval() a sole anonymous function expression. That is not a valid JavaScript statement, and so it is not a valid JavaScript script. COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for 1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200798#comment-13200798
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Alexander,
this isn't as off-topic as it seems at first, because software design is
heavily influenced by ease of testability.
I've not proposed to inject every single function. I've proposed to inject the
context. For a list function it may be:
function aList(head, req, ctx) {
var row;
function renderRow(row) { //... }
while((row = ctx.getRow())) {
send(renderRow(row));
}
}
This greatly simplifies unit testing. And it does not imply that you mock
every internal query server global function. You can even do without mocking,
but the point is that you are in control of it, so you can properly test
whatever needs testing.
Testing with the real query server, is done in end-to-end or integration
testing. This is needed, but it does not eliminate the need for unit testing.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200384#comment-13200384
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Jason,
I've found that, using valid Javascript in map/reduce, eases development for
me, because I can use standard tools (uglifyjs, jshint, ...) without extra work.
Moreover, I would also remove all global functions and inject them:
function sampleMap(doc, view) {
view.emit(doc._id, null);
}
because this makes unit testing much more easier than now.
Ease of development and ease of testing it's much more relaxing for me, than
the possibility to use anonymous functions.
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200471#comment-13200471
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Jason,
CommonJS is fine, but it doesn't help for unit testing. CommonJS is a linker
(runs on load time), dependency injection is done at run-time. One assembles
code, the other object graph. Not the same thing.
To ease unit testing, you need dependency injection. You can't easily test:
function (doc) {
var util = require('views/lib/util');
if (util.isSomething(doc)) {
emit(doc._id, 1);
}
}
It's doable (I'm doing it), but not easy. Testing the following is trivial:
function (doc, view, require) {
var util = require('views/lib/util');
if (util.isSomething(doc)) {
view.emit(doc._id, 1);
}
}
Globals, make the code harder to:
- read (where do these values come from?);
- test (how do I mock globals at run-time?);
- write (you need to tell to your code-checker what globals you use.)
Function expressions, evals in SpiderMonkey
---
Key: COUCHDB-1397
URL: https://issues.apache.org/jira/browse/COUCHDB-1397
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 1.2.1
Environment: All
Reporter: Jason Smith
New SpiderMonkey releases do not eval() a sole anonymous function expression.
That is not a valid JavaScript statement, and so it is not a valid JavaScript
script.
COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
1.2. (Sorry to spam COUCHDB-1302. I saw Unassigned and read Unresolved.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1206) View ETags may be incorrect if ?include_docs=true is specified
[ https://issues.apache.org/jira/browse/COUCHDB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13189052#comment-13189052 ] Marcello Nuccio commented on COUCHDB-1206: -- This fix does not work with `_all_docs` view. Tested on CouchDB-1.1.1. View ETags may be incorrect if ?include_docs=true is specified -- Key: COUCHDB-1206 URL: https://issues.apache.org/jira/browse/COUCHDB-1206 Project: CouchDB Issue Type: Bug Affects Versions: 1.1 Reporter: Jens Alfke Assignee: Robert Newson Priority: Minor Fix For: 1.1.1, 1.2 Change COUCHDB-799 altered the way ETags are assigned to views, by having the ETag change only when the view index changes, not when any document changes. Unfortunately this means that a view with the ?include_docs=true option can return an incorrect ETag. The reason is that if a document in the view is changed, but the change doesn't affect the view index, the result of the GET will change (it will contain the document's updated contents), but the ETag won't. This can result in stale data if the client uses a conditional GET, because it'll get a 304 even though the prior response is out of date. Robert Newson's analysis on the user@ list is I think the sanest fix is to make view etags for include_docs=true use the original algorithm, so that they always change if the database changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1206) View ETags may be incorrect if ?include_docs=true is specified
[ https://issues.apache.org/jira/browse/COUCHDB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13189063#comment-13189063 ] Marcello Nuccio commented on COUCHDB-1206: -- The following queries return the same ETag, but different bodies (I have created two docs with id1 and id2): curl -v http://localhost:5984/db/_all_docs'?keys=%5B%22id1%22,%22id2%22%5D' curl -v http://localhost:5984/db/_all_docs'?keys=%5B%22id1%22,%22id2%22%5Dinclude_docs=true' If I do the same query on a custom view, the ETag changes. View ETags may be incorrect if ?include_docs=true is specified -- Key: COUCHDB-1206 URL: https://issues.apache.org/jira/browse/COUCHDB-1206 Project: CouchDB Issue Type: Bug Affects Versions: 1.1 Reporter: Jens Alfke Assignee: Robert Newson Priority: Minor Fix For: 1.1.1, 1.2 Change COUCHDB-799 altered the way ETags are assigned to views, by having the ETag change only when the view index changes, not when any document changes. Unfortunately this means that a view with the ?include_docs=true option can return an incorrect ETag. The reason is that if a document in the view is changed, but the change doesn't affect the view index, the result of the GET will change (it will contain the document's updated contents), but the ETag won't. This can result in stale data if the client uses a conditional GET, because it'll get a 304 even though the prior response is out of date. Robert Newson's analysis on the user@ list is I think the sanest fix is to make view etags for include_docs=true use the original algorithm, so that they always change if the database changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1206) View ETags may be incorrect if ?include_docs=true is specified
[ https://issues.apache.org/jira/browse/COUCHDB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13189071#comment-13189071 ] Marcello Nuccio commented on COUCHDB-1206: -- OK, it's time to go to sleep... sorry... :-) View ETags may be incorrect if ?include_docs=true is specified -- Key: COUCHDB-1206 URL: https://issues.apache.org/jira/browse/COUCHDB-1206 Project: CouchDB Issue Type: Bug Affects Versions: 1.1 Reporter: Jens Alfke Assignee: Robert Newson Priority: Minor Fix For: 1.1.1, 1.2 Change COUCHDB-799 altered the way ETags are assigned to views, by having the ETag change only when the view index changes, not when any document changes. Unfortunately this means that a view with the ?include_docs=true option can return an incorrect ETag. The reason is that if a document in the view is changed, but the change doesn't affect the view index, the result of the GET will change (it will contain the document's updated contents), but the ETag won't. This can result in stale data if the client uses a conditional GET, because it'll get a 304 even though the prior response is out of date. Robert Newson's analysis on the user@ list is I think the sanest fix is to make view etags for include_docs=true use the original algorithm, so that they always change if the database changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1206) View ETags may be incorrect if ?include_docs=true is specified
[ https://issues.apache.org/jira/browse/COUCHDB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13189645#comment-13189645 ] Marcello Nuccio commented on COUCHDB-1206: -- Yes. I've realized that the URL was different in the moment that Robert asked Erm, so what?... It was a long working day... View ETags may be incorrect if ?include_docs=true is specified -- Key: COUCHDB-1206 URL: https://issues.apache.org/jira/browse/COUCHDB-1206 Project: CouchDB Issue Type: Bug Affects Versions: 1.1 Reporter: Jens Alfke Assignee: Robert Newson Priority: Minor Fix For: 1.1.1, 1.2 Change COUCHDB-799 altered the way ETags are assigned to views, by having the ETag change only when the view index changes, not when any document changes. Unfortunately this means that a view with the ?include_docs=true option can return an incorrect ETag. The reason is that if a document in the view is changed, but the change doesn't affect the view index, the result of the GET will change (it will contain the document's updated contents), but the ETag won't. This can result in stale data if the client uses a conditional GET, because it'll get a 304 even though the prior response is out of date. Robert Newson's analysis on the user@ list is I think the sanest fix is to make view etags for include_docs=true use the original algorithm, so that they always change if the database changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-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:comment-tabpanelfocusedCommentId=13176641#comment-13176641 ] Marcello Nuccio commented on COUCHDB-1371: -- Isn't the real problem that all this testing is not fully automated? In an ideal world, there should be a continuous integration server relieving all these burden from the developers. Is something like what is described in the video at http://www.youtube.com/watch?v=5GGMa6mmcg0 doable with CouchDB? Or there are technical limitations preventing this? 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] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses
[ https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13153431#comment-13153431 ] Marcello Nuccio commented on COUCHDB-1175: -- Ari, there's no easy fix. Luckily, you have an easy workaround: put the data in a secure db, and the application in a read-only db (or HTTP server). Improve content type negotiation for couchdb JSON responses --- Key: COUCHDB-1175 URL: https://issues.apache.org/jira/browse/COUCHDB-1175 Project: CouchDB Issue Type: Improvement Affects Versions: 1.0.2 Reporter: Robert Newson Priority: Blocker Fix For: 1.2 Currently we ignore qvalues when negotiation between 'application/json' and 'text/plain' when returning JSON responses. Specifically, we test directly for 'application/json' or 'text/plain' in the Accept header. Different branches have different bugs, though. Trunk returns 'application/json' if 'application/json' is present at all, even if it's less preferred than 'text/plain' when qvalues are accounted for. We should follow the standard. -- 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
