[jira] [Created] (COUCHDB-2674) Inconsistent handling of URL encoded design doc name between clustered and non-clustered interfaces
Will Holley created COUCHDB-2674:
Summary: Inconsistent handling of URL encoded design doc name
between clustered and non-clustered interfaces
Key: COUCHDB-2674
URL: https://issues.apache.org/jira/browse/COUCHDB-2674
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Database Core
Reporter: Will Holley
In CouchDB 1.6 (and non-clustered 2.X), a request to GET a design document
where the full design document name is URL encoded results in a 301 redirect:
{code}
$ curl -v http://127.0.0.1:15986/test/_design%2Ffoo
> GET /test/_design%2Ffoo HTTP/1.1
> User-Agent: curl/7.37.1
> Host: 127.0.0.1:15986
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
* Server CouchDB/44fe5b6 (Erlang OTP/17) is not blacklisted
< Server: CouchDB/44fe5b6 (Erlang OTP/17)
< Location: http://127.0.0.1:15986/test/_design/foo
< Date: Sun, 26 Apr 2015 18:18:30 GMT
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact
{code}
However, the same request through the clustered interface is handled directly:
{code}
$ curl -v http://127.0.0.1:15984/test/_design%2Ffoo
> GET /test/_design%2Ffoo HTTP/1.1
> User-Agent: curl/7.37.1
> Host: 127.0.0.1:15984
> Accept: */*
>
< HTTP/1.1 200 OK
< X-CouchDB-Body-Time: 0
< X-Couch-Request-ID: f9a8af50
* Server CouchDB/44fe5b6 (Erlang OTP/17) is not blacklisted
< Server: CouchDB/44fe5b6 (Erlang OTP/17)
< Etag: "1-670d087e023b4320c148c8e73ba82129"
< Date: Sun, 26 Apr 2015 18:16:51 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 160
< Cache-Control: must-revalidate
<
{"_id":"_design/foo","_rev":"1-670d087e023b4320c148c8e73ba82129","views":{"newView":{"map":"function(doc)
{\n emit(doc._id, 1);\n}"}},"language":"javascript"}
* Connection #0 to host 127.0.0.1 left intact
{code}
I think the behaviour in the clustered interface is preferable but we should be
consistent. The difference seems to be at
https://github.com/apache/couchdb-chttpd/blob/ab80f3131e244af967e2d162925ee45008d54a50/src/chttpd_db.erl#L512.
This came to light due to the .NET HTTP client not sending authentication
headers when following the redirect (see
https://github.com/danielwertheim/mycouch/issues/75).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
dev@couchdb.apache.org
[
https://issues.apache.org/jira/browse/COUCHDB-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Holley updated COUCHDB-2568:
-
Description:
Similar to case COUCHDB-2522, in CouchDB 1.6,
'/_all_docs'?keys=["somekey"]&include_docs=true&attachments=true' returns the
full attachment data. In the clustered CouchDB 2.0 interface, the attachments
query parameter is ignored.
In CouchDB 1.6:
{code}
~$ curl -X PUT http://127.0.0.1:5984/test
{"ok":true}
~$ curl -X POST http://127.0.0.1:5984/test -H 'Content-type:application/json'
-d '{ "_id": "foo", "_attachments": { "bar.txt": {"content_type":
"text/plain","data": "holy moly"} } }'
{"ok":true,"id":"foo","rev":"1-b4adf85456c3026765ddee2d36c3814f"}
~$ curl -g
'http://127.0.0.1:5984/test/_all_docs?keys=["foo"]&include_docs=true&attachments=true'
{"total_rows":1,"offset":0,"rows":[
{"id":"foo","key":"foo","value":{"rev":"1-b4adf85456c3026765ddee2d36c3814f"},"doc":{"_id":"foo","_rev":"1-b4adf85456c3026765ddee2d36c3814f","_attachments":{"bar.txt":{"content_type":"text/plain","revpos":1,"digest":"md5-iRNdzYnZ/dk8u44XAJXaAQ==","data":"holymoly"
]}
{code}
In CouchDB 2.0:
{code}
~$ curl -X PUT http://127.0.0.1:15984/test
{"ok":true}
~$ curl -X POST http://127.0.0.1:15984/test -H 'Content-type:application/json'
-d '{ "_id": "foo", "_attachments": { "bar.txt": {"content_type":
"text/plain","data": "holy moly"} } }'
{"ok":true,"id":"foo","rev":"1-b4adf85456c3026765ddee2d36c3814f"}
~$ curl -g
'http://127.0.0.1:15984/test/_all_docs?keys=["foo"]&include_docs=true&attachments=true'
{"total_rows":1,"rows":[
{"id":"foo","key":"foo","value":{"rev":"1-b4adf85456c3026765ddee2d36c3814f"},"doc":{"_id":"foo","_rev":"1-b4adf85456c3026765ddee2d36c3814f","_attachments":{"bar.txt":{"content_type":"text/plain","revpos":1,"digest":"md5-iRNdzYnZ/dk8u44XAJXaAQ==","length":6,"stub":true
]}
{code}
was:Similar to case COUCHDB-2522, in CouchDB 1.6,
'/_all_docs'?keys=["somekey"]&include_docs=true&attachments=true' returns the
full attachment data. In the clustered CouchDB 2.0 interface, the attachments
query parameter is ignored.
> CouchDB 2.0 /_all_docs does not return full attachment data with
> keys=["somekey"]&attachments=true
> --
>
> Key: COUCHDB-2568
> URL: https://issues.apache.org/jira/browse/COUCHDB-2568
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
>Reporter: Will Holley
>
> Similar to case COUCHDB-2522, in CouchDB 1.6,
> '/_all_docs'?keys=["somekey"]&include_docs=true&attachments=true' returns the
> full attachment data. In the clustered CouchDB 2.0 interface, the attachments
> query parameter is ignored.
> In CouchDB 1.6:
> {code}
> ~$ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> ~$ curl -X POST http://127.0.0.1:5984/test -H 'Content-type:application/json'
> -d '{ "_id": "foo", "_attachments": { "bar.txt": {"content_type":
> "text/plain","data": "holy moly"} } }'
> {"ok":true,"id":"foo","rev":"1-b4adf85456c3026765ddee2d36c3814f"}
> ~$ curl -g
> 'http://127.0.0.1:5984/test/_all_docs?keys=["foo"]&include_docs=true&attachments=true'
> {"total_rows":1,"offset":0,"rows":[
> {"id":"foo","key":"foo","value":{"rev":"1-b4adf85456c3026765ddee2d36c3814f"},"doc":{"_id":"foo","_rev":"1-b4adf85456c3026765ddee2d36c3814f","_attachments":{"bar.txt":{"content_type":"text/plain","revpos":1,"digest":"md5-iRNdzYnZ/dk8u44XAJXaAQ==","data":"holymoly"
> ]}
> {code}
> In CouchDB 2.0:
> {code}
> ~$ curl -X PUT http://127.0.0.1:15984/test
> {"ok":true}
> ~$ curl -X POST http://127.0.0.1:15984/test -H
> 'Content-type:application/json' -d '{ "_id": "foo", "_attachments": {
> "bar.txt": {"content_type": "text/plain","data": "holy moly"} } }'
> {"ok":true,"id":"foo","rev":"1-b4adf85456c3026765ddee2d36c3814f"}
> ~$ curl -g
> 'http://127.0.0.1:15984/test/_all_docs?keys=["foo"]&include_docs=true&attachments=true'
> {"total_rows":1,"rows":[
> {"id":"foo","key":"foo","value":{"rev":"1-b4adf85456c3026765ddee2d36c3814f"},"doc":{"_id":"foo","_rev":"1-b4adf85456c3026765ddee2d36c3814f","_attachments":{"bar.txt":{"content_type":"text/plain","revpos":1,"digest":"md5-iRNdzYnZ/dk8u44XAJXaAQ==","length":6,"stub":true
> ]}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
dev@couchdb.apache.org
[ https://issues.apache.org/jira/browse/COUCHDB-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Holley updated COUCHDB-2568: - Description: Similar to case COUCHDB-2522, in CouchDB 1.6, '/_all_docs'?keys=["somekey"]&include_docs=true&attachments=true' returns the full attachment data. In the clustered CouchDB 2.0 interface, the attachments query parameter is ignored. (was: Similar to case COUCHDB-2522, in CouchDB 1.6, '/_all_docs'?include_docs=true&attachments=true' returns the full attachment data. In the clustered CouchDB 2.0 interface, the attachments query parameter is ignored.) > CouchDB 2.0 /_all_docs does not return full attachment data with > keys=["somekey"]&attachments=true > -- > > Key: COUCHDB-2568 > URL: https://issues.apache.org/jira/browse/COUCHDB-2568 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Database Core >Reporter: Will Holley > > Similar to case COUCHDB-2522, in CouchDB 1.6, > '/_all_docs'?keys=["somekey"]&include_docs=true&attachments=true' returns the > full attachment data. In the clustered CouchDB 2.0 interface, the attachments > query parameter is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
dev@couchdb.apache.org
[ https://issues.apache.org/jira/browse/COUCHDB-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Holley updated COUCHDB-2568: - Summary: CouchDB 2.0 /_all_docs does not return full attachment data with keys=["somekey"]&attachments=true (was: CouchDB 2.0 /_all_docs does not return full attachment data with attachments=true) > CouchDB 2.0 /_all_docs does not return full attachment data with > keys=["somekey"]&attachments=true > -- > > Key: COUCHDB-2568 > URL: https://issues.apache.org/jira/browse/COUCHDB-2568 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Database Core >Reporter: Will Holley > > Similar to case COUCHDB-2522, in CouchDB 1.6, > '/_all_docs'?include_docs=true&attachments=true' returns the full attachment > data. In the clustered CouchDB 2.0 interface, the attachments query parameter > is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2568) CouchDB 2.0 /_all_docs does not return full attachment data with attachments=true
Will Holley created COUCHDB-2568: Summary: CouchDB 2.0 /_all_docs does not return full attachment data with attachments=true Key: COUCHDB-2568 URL: https://issues.apache.org/jira/browse/COUCHDB-2568 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Database Core Reporter: Will Holley Similar to case COUCHDB-2522, in CouchDB 1.6, '/_all_docs'?include_docs=true&attachments=true' returns the full attachment data. In the clustered CouchDB 2.0 interface, the attachments query parameter is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2537) Propose removal of ?local_seq=true from the GET /db/doc API for CouchDB 2.0
[
https://issues.apache.org/jira/browse/COUCHDB-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303676#comment-14303676
]
Will Holley commented on COUCHDB-2537:
--
I'm happy to be shot down but I wouldn't really expect CouchDB to work
correctly if documents are submitted with _revs that don't conform to the spec.
If two documents have exactly the same _id/_rev then they should have the same
content / lineage (because CouchDB relies on hash histories).
> Propose removal of ?local_seq=true from the GET /db/doc API for CouchDB 2.0
> ---
>
> Key: COUCHDB-2537
> URL: https://issues.apache.org/jira/browse/COUCHDB-2537
> Project: CouchDB
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Database Core
>Reporter: Glynn Bird
>
> Prior to CouchDB 2.0, a document could be fetched thus:
> /db/8E795956?local_seq=true
> {Code}
> { _id: '8E795956',
> _rev: '1-4fffae881c4d89048cf9319c2ae021a1',
> test: 'somestuff',
> _local_seq: 1 }
> {Code}
> with the _local_seq being returned indicating 'Document’s sequence number in
> current database'.
> Post CouchDB2.0, this quantity makes little sense as it represents the local
> sequence number within the shard.
> I propose that
> * ?local_seq=true is deprecated
> * _local_seq is no longer returned in the response
> * the documentation is updated accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2531) CouchDB 2.0: POST to /_revs_diff with no revisions times out
Will Holley created COUCHDB-2531:
Summary: CouchDB 2.0: POST to /_revs_diff with no revisions times
out
Key: COUCHDB-2531
URL: https://issues.apache.org/jira/browse/COUCHDB-2531
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Will Holley
In CouchDB 1.6, posting an empty object to the _revs_diff endpoint returns an
empty object:
{code}
$ curl http://127.0.0.1:5984/revsdifftest -XPUT
{"ok":true}
$ curl http://127.0.0.1:5984/revsdifftest/_revs_diff -XPOST
-H"Content-Type:application/json" -d"{}"
{}
{code}
In CouchDB 2.0, the same request results in a timeout:
{code}
$ curl http://127.0.0.1:15984/revsdifftest -XPUT
{"ok":true}
$ curl http://127.0.0.1:15984/revsdifftest/_revs_diff -XPOST
-H"Content-Type:application/json" -d"{}"
{"error":"badmatch","reason":"{error,timeout}","ref":1478668763}
{code}
This currently breaks the PouchDB test suite when running against CouchDB
master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2530) CouchDB 2.0 does not support POST requests to _changes
[
https://issues.apache.org/jira/browse/COUCHDB-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Holley updated COUCHDB-2530:
-
Description:
In CouchDB 1.6, the _changes feed accepts a POST request (e.g. to submit a
large doc_ids parameter):
{code}
curl http://127.0.0.1:5984/testdb/_changes?filter=_doc_ids -XPOST
-H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
{"results":[
{"seq":1,"id":"1","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":1}
{code}
In CouchDB 2.0, this fails with a "405 Method Not Allowed" response:
{code}
curl http://127.0.0.1:15984/testdb/_changes?filter=_doc_ids -XPOST
-H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
{"error":"method_not_allowed","reason":"Only GET,HEAD allowed"}
{code}
was:
In CouchDB 1.6, the _changes feed accepts a POST request (e.g. to submit a
large doc_ids parameter):
{code}
curl http://127.0.0.1:5984/testdb/_changes -XPOST
-H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
{"results":[
{"seq":1,"id":"1","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":1}
{code}
In CouchDB 2.0, this fails with a "405 Method Not Allowed" response:
{code}
curl http://127.0.0.1:15984/testdb/_changes -XPOST
-H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
{"error":"method_not_allowed","reason":"Only GET,HEAD allowed"}
{code}
> CouchDB 2.0 does not support POST requests to _changes
> --
>
> Key: COUCHDB-2530
> URL: https://issues.apache.org/jira/browse/COUCHDB-2530
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Will Holley
>
> In CouchDB 1.6, the _changes feed accepts a POST request (e.g. to submit a
> large doc_ids parameter):
> {code}
> curl http://127.0.0.1:5984/testdb/_changes?filter=_doc_ids -XPOST
> -H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
> {"results":[
> {"seq":1,"id":"1","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
> ],
> "last_seq":1}
> {code}
> In CouchDB 2.0, this fails with a "405 Method Not Allowed" response:
> {code}
> curl http://127.0.0.1:15984/testdb/_changes?filter=_doc_ids -XPOST
> -H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
> {"error":"method_not_allowed","reason":"Only GET,HEAD allowed"}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2530) CouchDB 2.0 does not support POST requests to _changes
Will Holley created COUCHDB-2530:
Summary: CouchDB 2.0 does not support POST requests to _changes
Key: COUCHDB-2530
URL: https://issues.apache.org/jira/browse/COUCHDB-2530
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Will Holley
In CouchDB 1.6, the _changes feed accepts a POST request (e.g. to submit a
large doc_ids parameter):
{code}
curl http://127.0.0.1:5984/testdb/_changes -XPOST
-H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
{"results":[
{"seq":1,"id":"1","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]}
],
"last_seq":1}
{code}
In CouchDB 2.0, this fails with a "405 Method Not Allowed" response:
{code}
curl http://127.0.0.1:15984/testdb/_changes -XPOST
-H"Content-Type:application/json" -d '{"doc_ids":["1"]}'
{"error":"method_not_allowed","reason":"Only GET,HEAD allowed"}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2523) CouchDB 2.0: Specifying startkey/endkey parameters alongside a keys parameter when querying /_all_docs should be invalid
Will Holley created COUCHDB-2523:
Summary: CouchDB 2.0: Specifying startkey/endkey parameters
alongside a keys parameter when querying /_all_docs should be invalid
Key: COUCHDB-2523
URL: https://issues.apache.org/jira/browse/COUCHDB-2523
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Database Core
Reporter: Will Holley
CouchDB 1.X validates that the combination of query parameters to _all_docs is
valid. For instance, you cannot specify keys and also startkey/endkey:
{code}
curl -g -XGET 'http://127.0.0.1:5984/testdb/_all_docs?keys=["a"]&startkey="a";'
{"error":"query_parse_error","reason":"`keys` is incompatible with `key`,
`start_key` and `end_key`"}
{code}
In CouchDB 2.0, there is no such validation:
{code}
curl -g -XGET 'http://127.0.0.1:15984/testdb/_all_docs?keys=["a"]&startkey="a";'
{"total_rows":5,"rows":[
{"id":"a","key":"a","value":{"rev":"1-4c6114c65e295552ab1019e2b046b10e"}}
]}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2519) CouchDB 2.0 does not support attachments=true on /_changes
Will Holley created COUCHDB-2519: Summary: CouchDB 2.0 does not support attachments=true on /_changes Key: COUCHDB-2519 URL: https://issues.apache.org/jira/browse/COUCHDB-2519 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Database Core Reporter: Will Holley In CouchDB 1.X, querying /_changes?include_docs=true&attachments=true returns the binary attachment data in the changes feed. In CouchDB 2.0, the attachments=true parameter appears to be ignored - the changes feed includes stubs only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2518) CouchDB 2.0 does not support conflicts=true on /_changes
[
https://issues.apache.org/jira/browse/COUCHDB-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Holley updated COUCHDB-2518:
-
Description:
CouchDB 1.X supports the conflicts=true query parameter for all API endpints
which accept the include_docs parameter (since version 1.0.3 according to the
release notes). This appears to have regressed in CouchDB 2.0.
I've observed this in the PouchDB tests (which fail for this). Attempting to
reproduce in curl:
{code}
$ curl 'http://127.0.0.1:15984/test' -XPUT
{"ok":true}
$ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
-H'Content-Type:application/json' -XPUT
-d'{"_id":"foo","_rev":"2-aa01552213fafa022e6167113ed01087","value":"bar"}'
{"ok":true,"id":"foo","rev":"2-aa01552213fafa022e6167113ed01087"}
$ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
-H'Content-Type:application/json' -XPUT
-d'{"_id":"foo","_rev":"3-aa01552213fafa022e6167113ed01087","value":"baz"}'
{"ok":true,"id":"foo","rev":"3-aa01552213fafa022e6167113ed01087"}
$ curl 'http://127.0.0.1:15984/test/foo?conflicts=true' | jq .
{
"_id": "foo",
"_rev": "3-aa01552213fafa022e6167113ed01087",
"value": "baz",
"_conflicts": [
"2-aa01552213fafa022e6167113ed01087"
]
}
$curl 'http://127.0.0.1:15984/test/_changes?include_docs=true&conflicts=true' |
jq .
{
"results": [
{
"seq": [
2,
"g1GpeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MygKxcoAC7kbGFSZKpOU4NSQpAMskeRU9acopJqrExbj0OID3xKHoMDI0MTM2NcOtJAOmpR9GTCrTIMNkQrscITU8eC5BkaABSQG3zszKYE5nA-kyTzFNNLc0xdcFNMsZq0gKISfsRLkg0M7I0ME0h4IIDEH33sxIZCKh8AFH5H6gyCwCZjmsY"
],
"id": "foo",
"changes": [
{
"rev": "3-aa01552213fafa022e6167113ed01087"
}
],
"doc": {
"_id": "foo",
"_rev": "3-aa01552213fafa022e6167113ed01087",
"value": "baz"
}
}
],
"last_seq": [
2,
"g1GzeJyFz1EOgjAMBuAFTfTNI-gJzLpRB09yE6VshhDAI-hN9CZ6E73JLJKIGAlZ0jVtvvxpKYSY5xMrFvXROkhAmbXkByUvglTQ0ntf5NxVPJgpHYWEZhDQiitte-aQ2dBpPWySxux6RoKSaNSw2Tfm1DOOgyCDj1E_pp5yFWf-mF0aF7wdknEYdzfpv-7auluXl25ULNGO5N1b9-gcRia0EY24Z-u-7iNMyQEWL83XbI4"
],
"pending": 0
}
{code}
was:
CouchDB 1.X supports the conflicts=true query parameter for all API endpints
which accept the include_docs parameter (since version 1.0.3 according to the
release notes). This appears to have regressed in CouchDB 2.0.
I've observed this in the PouchDB tests (which fail for this). Attempting to
reproduce in curl:
$ curl 'http://127.0.0.1:15984/test' -XPUT
{"ok":true}
$ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
-H'Content-Type:application/json' -XPUT
-d'{"_id":"foo","_rev":"2-aa01552213fafa022e6167113ed01087","value":"bar"}'
{"ok":true,"id":"foo","rev":"2-aa01552213fafa022e6167113ed01087"}
$ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
-H'Content-Type:application/json' -XPUT
-d'{"_id":"foo","_rev":"3-aa01552213fafa022e6167113ed01087","value":"baz"}'
{"ok":true,"id":"foo","rev":"3-aa01552213fafa022e6167113ed01087"}
$ curl 'http://127.0.0.1:15984/test/foo?conflicts=true' | jq .
{
"_id": "foo",
"_rev": "3-aa01552213fafa022e6167113ed01087",
"value": "baz",
"_conflicts": [
"2-aa01552213fafa022e6167113ed01087"
]
}
$curl 'http://127.0.0.1:15984/test/_changes?include_docs=true&conflicts=true' |
jq .
{
"results": [
{
"seq": [
2,
"g1GpeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MygKxcoAC7kbGFSZKpOU4NSQpAMskeRU9acopJqrExbj0OID3xKHoMDI0MTM2NcOtJAOmpR9GTCrTIMNkQrscITU8eC5BkaABSQG3zszKYE5nA-kyTzFNNLc0xdcFNMsZq0gKISfsRLkg0M7I0ME0h4IIDEH33sxIZCKh8AFH5H6gyCwCZjmsY"
],
"id": "foo",
"changes": [
{
"rev": "3-aa01552213fafa022e6167113ed01087"
}
],
"doc": {
"_id": "foo",
"_rev": "3-aa01552213fafa022e6167113ed01087",
"value": "baz"
}
}
],
"last_seq": [
2,
"g1GzeJyFz1EOgjAMBuAFTfTNI-gJzLpRB09yE6VshhDAI-hN9CZ6E73JLJKIGAlZ0jVtvvxpKYSY5xMrFvXROkhAmbXkByUvglTQ0ntf5NxVPJgpHYWEZhDQiitte-aQ2dBpPWySxux6RoKSaNSw2Tfm1DOOgyCDj1E_pp5yFWf-mF0aF7wdknEYdzfpv-7auluXl25ULNGO5N1b9-gcRia0EY24Z-u-7iNMyQEWL83XbI4"
],
"pending": 0
}
> CouchDB 2.0 does not support conflicts=true on /_changes
>
>
> Key: COUCHDB-2518
> URL: https://issues.apache.org/jira/browse/COUCHDB-2518
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
>Reporter: Will Holley
>
> CouchDB 1.X supports the conflicts=true query parameter for all API endpints
> which accept the include_docs parameter (since version 1.0.3 according to the
> release notes). This appears to have regressed in CouchDB 2.0.
> I've observed this in the PouchDB tests (which fail for this). Attempting to
> reprod
[jira] [Updated] (COUCHDB-2518) CouchDB 2.0 does not support conflicts=true on /_changes
[
https://issues.apache.org/jira/browse/COUCHDB-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Holley updated COUCHDB-2518:
-
Description:
CouchDB 1.X supports the conflicts=true query parameter for all API endpints
which accept the include_docs parameter (since version 1.0.3 according to the
release notes). This appears to have regressed in CouchDB 2.0.
I've observed this in the PouchDB tests (which fail for this). Attempting to
reproduce in curl:
$ curl 'http://127.0.0.1:15984/test' -XPUT
{"ok":true}
$ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
-H'Content-Type:application/json' -XPUT
-d'{"_id":"foo","_rev":"2-aa01552213fafa022e6167113ed01087","value":"bar"}'
{"ok":true,"id":"foo","rev":"2-aa01552213fafa022e6167113ed01087"}
$ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
-H'Content-Type:application/json' -XPUT
-d'{"_id":"foo","_rev":"3-aa01552213fafa022e6167113ed01087","value":"baz"}'
{"ok":true,"id":"foo","rev":"3-aa01552213fafa022e6167113ed01087"}
$ curl 'http://127.0.0.1:15984/test/foo?conflicts=true' | jq .
{
"_id": "foo",
"_rev": "3-aa01552213fafa022e6167113ed01087",
"value": "baz",
"_conflicts": [
"2-aa01552213fafa022e6167113ed01087"
]
}
$curl 'http://127.0.0.1:15984/test/_changes?include_docs=true&conflicts=true' |
jq .
{
"results": [
{
"seq": [
2,
"g1GpeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MygKxcoAC7kbGFSZKpOU4NSQpAMskeRU9acopJqrExbj0OID3xKHoMDI0MTM2NcOtJAOmpR9GTCrTIMNkQrscITU8eC5BkaABSQG3zszKYE5nA-kyTzFNNLc0xdcFNMsZq0gKISfsRLkg0M7I0ME0h4IIDEH33sxIZCKh8AFH5H6gyCwCZjmsY"
],
"id": "foo",
"changes": [
{
"rev": "3-aa01552213fafa022e6167113ed01087"
}
],
"doc": {
"_id": "foo",
"_rev": "3-aa01552213fafa022e6167113ed01087",
"value": "baz"
}
}
],
"last_seq": [
2,
"g1GzeJyFz1EOgjAMBuAFTfTNI-gJzLpRB09yE6VshhDAI-hN9CZ6E73JLJKIGAlZ0jVtvvxpKYSY5xMrFvXROkhAmbXkByUvglTQ0ntf5NxVPJgpHYWEZhDQiitte-aQ2dBpPWySxux6RoKSaNSw2Tfm1DOOgyCDj1E_pp5yFWf-mF0aF7wdknEYdzfpv-7auluXl25ULNGO5N1b9-gcRia0EY24Z-u-7iNMyQEWL83XbI4"
],
"pending": 0
}
was:CouchDB 1.X supports the conflicts=true query parameter for all API
endpints which accept the include_docs parameter (since version 1.0.3 according
to the release notes). This appears to have regressed in CouchDB 2.0.
> CouchDB 2.0 does not support conflicts=true on /_changes
>
>
> Key: COUCHDB-2518
> URL: https://issues.apache.org/jira/browse/COUCHDB-2518
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
>Reporter: Will Holley
>
> CouchDB 1.X supports the conflicts=true query parameter for all API endpints
> which accept the include_docs parameter (since version 1.0.3 according to the
> release notes). This appears to have regressed in CouchDB 2.0.
> I've observed this in the PouchDB tests (which fail for this). Attempting to
> reproduce in curl:
> $ curl 'http://127.0.0.1:15984/test' -XPUT
> {"ok":true}
> $ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
> -H'Content-Type:application/json' -XPUT
> -d'{"_id":"foo","_rev":"2-aa01552213fafa022e6167113ed01087","value":"bar"}'
> {"ok":true,"id":"foo","rev":"2-aa01552213fafa022e6167113ed01087"}
> $ curl 'http://127.0.0.1:15984/test/foo?new_edits=false'
> -H'Content-Type:application/json' -XPUT
> -d'{"_id":"foo","_rev":"3-aa01552213fafa022e6167113ed01087","value":"baz"}'
> {"ok":true,"id":"foo","rev":"3-aa01552213fafa022e6167113ed01087"}
> $ curl 'http://127.0.0.1:15984/test/foo?conflicts=true' | jq .
> {
> "_id": "foo",
> "_rev": "3-aa01552213fafa022e6167113ed01087",
> "value": "baz",
> "_conflicts": [
> "2-aa01552213fafa022e6167113ed01087"
> ]
> }
> $curl 'http://127.0.0.1:15984/test/_changes?include_docs=true&conflicts=true'
> | jq .
> {
> "results": [
> {
> "seq": [
> 2,
>
> "g1GpeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MygKxcoAC7kbGFSZKpOU4NSQpAMskeRU9acopJqrExbj0OID3xKHoMDI0MTM2NcOtJAOmpR9GTCrTIMNkQrscITU8eC5BkaABSQG3zszKYE5nA-kyTzFNNLc0xdcFNMsZq0gKISfsRLkg0M7I0ME0h4IIDEH33sxIZCKh8AFH5H6gyCwCZjmsY"
> ],
> "id": "foo",
> "changes": [
> {
> "rev": "3-aa01552213fafa022e6167113ed01087"
> }
> ],
> "doc": {
> "_id": "foo",
> "_rev": "3-aa01552213fafa022e6167113ed01087",
> "value": "baz"
> }
> }
> ],
> "last_seq": [
> 2,
>
> "g1GzeJyFz1EOgjAMBuAFTfTNI-gJzLpRB09yE6VshhDAI-hN9CZ6E73JLJKIGAlZ0jVtvvxpKYSY5xMrFvXROkhAmbXkByUvglTQ0ntf5NxVPJgpHYWEZhDQiitte-aQ2dBpPWySxux6RoKSaNSw2Tfm1DOOgyCDj1E_pp5yFWf-mF0aF7wdknEYdzfpv-7auluXl25ULNGO5N1b9-gcRia0EY24Z-u-7iNMyQEWL83XbI4"
> ],
> "pending": 0
> }
--
T
[jira] [Created] (COUCHDB-2518) CouchDB 2.0 does not support conflicts=true on /_changes
Will Holley created COUCHDB-2518: Summary: CouchDB 2.0 does not support conflicts=true on /_changes Key: COUCHDB-2518 URL: https://issues.apache.org/jira/browse/COUCHDB-2518 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Database Core Reporter: Will Holley CouchDB 1.X supports the conflicts=true query parameter for all API endpints which accept the include_docs parameter (since version 1.0.3 according to the release notes). This appears to have regressed in CouchDB 2.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2249) Fauxton generates incorrect parameters when complex keys are specified
[
https://issues.apache.org/jira/browse/COUCHDB-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Holley resolved COUCHDB-2249.
--
Resolution: Fixed
> Fauxton generates incorrect parameters when complex keys are specified
> --
>
> Key: COUCHDB-2249
> URL: https://issues.apache.org/jira/browse/COUCHDB-2249
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Fauxton
>Reporter: Will Holley
>
> Fauxton is not stringifying user-defined query parameters correctly (added in
> the "Query Options" panel). This results in a query parameter being generated
> for each component of the complex key.
> For example, specifying a startkey of {noformat}["a","b"]{noformat} generates
> the URL
> {noformat}
> ?startkey[]=a&startkey[]=b
> {noformat}
> instead of:
> {noformat}
> ?startkey=["a","b"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (COUCHDB-2249) Fauxton generates incorrect parameters when complex keys are specified
Will Holley created COUCHDB-2249:
Summary: Fauxton generates incorrect parameters when complex keys
are specified
Key: COUCHDB-2249
URL: https://issues.apache.org/jira/browse/COUCHDB-2249
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Fauxton
Reporter: Will Holley
Fauxton is not stringifying user-defined query parameters correctly (added in
the "Query Options" panel). This results in a query parameter being generated
for each component of the complex key.
For example, specifying a startkey of {noformat}["a","b"]{noformat} generates
the URL
{noformat}
?startkey[]=a&startkey[]=b
{noformat}
instead of:
{noformat}
?startkey=["a","b"]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-2188) Pagination is broken if map fun emits more rows than page size is
[
https://issues.apache.org/jira/browse/COUCHDB-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922671#comment-13922671
]
Will Holley commented on COUCHDB-2188:
--
This sounds like it is not fixable using the pagination algorithm that uses
startkey / startkey_docid to iterate through the result set. I can only think
that in this case we'd have to use skip as a fallback in the case where the
returned results are exactly the same as the current page?
> Pagination is broken if map fun emits more rows than page size is
> -
>
> Key: COUCHDB-2188
> URL: https://issues.apache.org/jira/browse/COUCHDB-2188
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Fauxton
>Reporter: Alexander Shorin
>
> 1. Create new database with single doc - his content doesn't matters
> 2. Create the view that emits multiple rows for single doc, like:
> {code}
> function(doc){
> for(var i=0; i < 20; i++){
> emit(doc._id, i);
> }
> }
> {code}
> Yes, too synthetic, but you got the idea.
> 3. Try to navigate thought results with page size 5 and 10 - you'll always
> browse the same content
> Fauxton @
> [4e60f0b|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=4e60f0b]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (COUCHDB-1935) Fauxton should show API URLs
[ https://issues.apache.org/jira/browse/COUCHDB-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825160#comment-13825160 ] Will Holley commented on COUCHDB-1935: -- There is already a collapsable "API URL" section at the top of the interface. Can you elaborate on what is needed beyond this or, if you hadn't found it, how the usability might be improved? > Fauxton should show API URLs > > > Key: COUCHDB-1935 > URL: https://issues.apache.org/jira/browse/COUCHDB-1935 > Project: CouchDB > Issue Type: Bug > Components: Fauxton >Reporter: Noah Slater > > When playing around with Fauxton, it would be super handy to grab the API > URLs that Fauxton is using to request data from CouchDB. I could then plug > them into an app I am working on. This turns Fauxton into a bit of an > instructional API URL builder for beginners. -- This message was sent by Atlassian JIRA (v6.1#6144)
