[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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%5D&include_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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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
