[jira] [Closed] (COUCHDB-2676) DELETE of a database returns JSON answer with type text/plain
[
https://issues.apache.org/jira/browse/COUCHDB-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-2676.
-
Resolution: Not A Problem
It's a content type negotiation where for {{Accept: */*}} text/plain is
preferred in the way to make API be friendly for the browsers.
{code}
http delete http://localhost:5984/test 'Accept:application/json'
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: application/json
Date: Mon, 27 Apr 2015 15:56:00 GMT
Server: CouchDB/1.6.1 (Erlang OTP/17)
{
"ok": true
}
{code}
If you explicitly ask for application/json response - you'll get it. Same is
true for the most of other endpoints. Search for "content negotiation" on JIRA
for more info about that behaviour.
> DELETE of a database returns JSON answer with type text/plain
> -
>
> Key: COUCHDB-2676
> URL: https://issues.apache.org/jira/browse/COUCHDB-2676
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: HTTP Interface
>Affects Versions: 1.6.1
>Reporter: Samuel Tardieu
>
> DELETE should return its response with a "application/json" MIME type.
> {code}
> % curl -v -X DELETE http://localhost:5984/test
> * Trying ::1...
> * Connected to localhost (::1) port 5984 (#0)
> > DELETE /test HTTP/1.1
> > Host: localhost:5984
> > User-Agent: curl/7.42.0
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Server: CouchDB/1.6.1 (Erlang OTP/17)
> < Date: Mon, 27 Apr 2015 15:30:14 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 12
> < Cache-Control: must-revalidate
> <
> {"ok":true}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2656) Update couch_mrview to use chttpd provided functions
[ https://issues.apache.org/jira/browse/COUCHDB-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2656. --- Resolution: Fixed All merged. Thank you! > Update couch_mrview to use chttpd provided functions > > > Key: COUCHDB-2656 > URL: https://issues.apache.org/jira/browse/COUCHDB-2656 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Database Core >Reporter: ILYA >Assignee: ILYA > > couch_mrview uses functions from couch_http. For example > send_external_response is used by couch_mrview_show. This brakes CORS > support. Since couch_httpd's version of send_external_response doesn't have > support for CORS compared to chttpd's version > https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_external.erl#L127. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COUCHDB-2589) Control lager via couch-config
[ https://issues.apache.org/jira/browse/COUCHDB-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-2589. - Resolution: Duplicate Fix Version/s: (was: 2.0.0) > Control lager via couch-config > -- > > Key: COUCHDB-2589 > URL: https://issues.apache.org/jira/browse/COUCHDB-2589 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core, Logging >Affects Versions: 2.0.0 >Reporter: Alexander Shorin >Priority: Blocker > > Currently, there are no ways to control lager logging level, output file and > other bits from config API. The related code is already exists in rcouch > merge branch, we need just pick it up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COUCHDB-2407) Improve docs, error messages, bootstrap process for database updates feed
[
https://issues.apache.org/jira/browse/COUCHDB-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-2407.
-
Resolution: Done
/_global_changes database is now created on cluster setup, heartbeat accept of
booleans is fixed, for eventsource feed support there is COUCHDB-2665 issue.
> Improve docs, error messages, bootstrap process for database updates feed
> --
>
> Key: COUCHDB-2407
> URL: https://issues.apache.org/jira/browse/COUCHDB-2407
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: HTTP Interface
>Affects Versions: 2.0.0
>Reporter: Alexander Shorin
>
> For current state of CouchDB 2.0 (not sure to which commit make a reference,
> just for "today") it acts very inconsistent:
> {code}
> http --json http://localhost:15984/_db_updates
> HTTP/1.1 404 Object Not Found
> Cache-Control: must-revalidate
> Content-Length: 58
> Content-Type: application/json
> Date: Sat, 25 Oct 2014 13:42:25 GMT
> Server: CouchDB/40c5c85 (Erlang OTP/17)
> X-Couch-Request-ID: 27e8ab2a
> X-CouchDB-Body-Time: 0
> {
> "error": "not_found",
> "reason": "Database does not exist."
> }
> {code}
> Ok, there is no such database. But wait:
> {code}
> http --json 'http://localhost:15984/_db_updates?feed=eventsource'
> HTTP/1.1 400 Bad Request
> Cache-Control: must-revalidate
> Content-Length: 88
> Content-Type: application/json
> Date: Sat, 25 Oct 2014 13:39:59 GMT
> Server: CouchDB/40c5c85 (Erlang OTP/17)
> X-Couch-Request-ID: 3a5ca656
> X-CouchDB-Body-Time: 0
> {
> "error": "bad_request",
> "reason": "Supported `feed` types: normal, continuous, longpoll"
> }
> {code}
> The eventsource feed type is supported by CouchDB 1.x. Ok, let's try
> suggested continuous one:
> {code}
> http --json
> 'http://localhost:15984/_db_updates?timeout=1000&heartbeat=false&feed=continuous'
> HTTP/1.1 400 Bad Request
> Cache-Control: must-revalidate
> Content-Length: 51
> Content-Type: application/json
> Date: Sat, 25 Oct 2014 13:50:59 GMT
> Server: CouchDB/40c5c85 (Erlang OTP/17)
> X-Couch-Request-ID: 6c560dc2
> X-CouchDB-Body-Time: 0
> {
> "error": "bad_request",
> "reason": "invalid_integer"
> }
> {code}
> The same request is correct for CouchDB 1.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COUCHDB-2668) Regression: attachment Etag references to document revision, not to digest
[
https://issues.apache.org/jira/browse/COUCHDB-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-2668.
-
Assignee: Robert Newson
> Regression: attachment Etag references to document revision, not to digest
> --
>
> Key: COUCHDB-2668
> URL: https://issues.apache.org/jira/browse/COUCHDB-2668
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core, HTTP Interface
>Reporter: Alexander Shorin
>Assignee: Robert Newson
>Priority: Blocker
> Fix For: 2.0.0
>
>
> In CouchDB 1.6.1:
> {code}
> $ curl -XPUT http://localhost:5984/db/doc/att -d 'Hello, CouchDB!' -H
> "Content-Type: text/plain"
> {"ok":true,"id":"doc","rev":"1-3ead39fb9d2538602f817e0bdc00fe26"}
> $ curl -XGET -v http://localhost:5984/db/doc/att
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /db/doc/att HTTP/1.1
> > User-Agent: curl/7.39.0
> > Host: localhost:5984
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Server: CouchDB/1.7.0 (Erlang OTP/17)
> < ETag: "+4vGmBKGmQoMe7ojcTyiSA=="
> < Date: Sun, 19 Apr 2015 01:17:41 GMT
> < Content-Type: text/plain
> < Content-Length: 15
> < Cache-Control: must-revalidate
> < Accept-Ranges: none
> <
> * Connection #0 to host localhost left intact
> Hello, CouchDB!%
> {code}
> In CouchDB 2.0:
> {code}
> $ curl -XPUT http://localhost:15984/db/doc/att -d 'Hello, CouchDB!' -H
> "Content-Type: text/plain"
> {"ok":true,"id":"doc","rev":"1-3ead39fb9d2538602f817e0bdc00fe26"}
> $ curl -XGET -v http://localhost:15984/db/doc/att
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 15984 (#0)
> > GET /db/doc/att HTTP/1.1
> > User-Agent: curl/7.39.0
> > Host: localhost:15984
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Server: CouchDB/42c9047 (Erlang OTP/17)
> < ETag: "1-3ead39fb9d2538602f817e0bdc00fe26"
> < Date: Sun, 19 Apr 2015 01:14:11 GMT
> < Content-Type: text/plain
> < Content-Length: 15
> < Cache-Control: must-revalidate
> < Accept-Ranges: none
> <
> * Connection #0 to host localhost left intact
> Hello, CouchDB!%
> {code}
> If document becomes updated, but attachment does not, their Etag changes as
> well:
> {code}
> $ curl -XGET -v http://localhost:15984/db/doc/att
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 15984 (#0)
> > GET /db/doc/att HTTP/1.1
> > User-Agent: curl/7.39.0
> > Host: localhost:15984
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Server: CouchDB/42c9047 (Erlang OTP/17)
> < ETag: "3-90c8a1947115ffb2032a217ed3d3c624"
> < Date: Sun, 19 Apr 2015 01:15:55 GMT
> < Content-Type: text/plain
> < Content-Length: 15
> < Cache-Control: must-revalidate
> < Accept-Ranges: none
> <
> * Connection #0 to host localhost left intact
> Hello, CouchDB!%
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COUCHDB-2669) Ybyhbyhby
[ https://issues.apache.org/jira/browse/COUCHDB-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-2669. - Resolution: Invalid > Ybyhbyhby > --- > > Key: COUCHDB-2669 > URL: https://issues.apache.org/jira/browse/COUCHDB-2669 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: ASF subversion and git services > Attachments: image.jpg > > > Ybyhbyhby > *Reporter*: Ollie > *E-mail*: [mailto:ollie2...@live.se] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2668) Regression: attachment Etag references to document revision, not to digest
Alexander Shorin created COUCHDB-2668:
-
Summary: Regression: attachment Etag references to document
revision, not to digest
Key: COUCHDB-2668
URL: https://issues.apache.org/jira/browse/COUCHDB-2668
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Database Core, HTTP Interface
Reporter: Alexander Shorin
In CouchDB 1.6.1:
{code}
$ curl -XPUT http://localhost:5984/db/doc/att -d 'Hello, CouchDB!' -H
"Content-Type: text/plain"
{"ok":true,"id":"doc","rev":"1-3ead39fb9d2538602f817e0bdc00fe26"}
$ curl -XGET -v http://localhost:5984/db/doc/att
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5984 (#0)
> GET /db/doc/att HTTP/1.1
> User-Agent: curl/7.39.0
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/1.7.0 (Erlang OTP/17)
< ETag: "+4vGmBKGmQoMe7ojcTyiSA=="
< Date: Sun, 19 Apr 2015 01:17:41 GMT
< Content-Type: text/plain
< Content-Length: 15
< Cache-Control: must-revalidate
< Accept-Ranges: none
<
* Connection #0 to host localhost left intact
Hello, CouchDB!%
{code}
In CouchDB 2.0:
{code}
$ curl -XPUT http://localhost:15984/db/doc/att -d 'Hello, CouchDB!' -H
"Content-Type: text/plain"
{"ok":true,"id":"doc","rev":"1-3ead39fb9d2538602f817e0bdc00fe26"}
$ curl -XGET -v http://localhost:15984/db/doc/att
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 15984 (#0)
> GET /db/doc/att HTTP/1.1
> User-Agent: curl/7.39.0
> Host: localhost:15984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/42c9047 (Erlang OTP/17)
< ETag: "1-3ead39fb9d2538602f817e0bdc00fe26"
< Date: Sun, 19 Apr 2015 01:14:11 GMT
< Content-Type: text/plain
< Content-Length: 15
< Cache-Control: must-revalidate
< Accept-Ranges: none
<
* Connection #0 to host localhost left intact
Hello, CouchDB!%
{code}
If document becomes updated, but attachment does not, their Etag changes as
well:
{code}
$ curl -XGET -v http://localhost:15984/db/doc/att
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 15984 (#0)
> GET /db/doc/att HTTP/1.1
> User-Agent: curl/7.39.0
> Host: localhost:15984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/42c9047 (Erlang OTP/17)
< ETag: "3-90c8a1947115ffb2032a217ed3d3c624"
< Date: Sun, 19 Apr 2015 01:15:55 GMT
< Content-Type: text/plain
< Content-Length: 15
< Cache-Control: must-revalidate
< Accept-Ranges: none
<
* Connection #0 to host localhost left intact
Hello, CouchDB!%
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2667) Regression: /_db_updates response format changed
Alexander Shorin created COUCHDB-2667:
-
Summary: Regression: /_db_updates response format changed
Key: COUCHDB-2667
URL: https://issues.apache.org/jira/browse/COUCHDB-2667
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: HTTP Interface
Reporter: Alexander Shorin
In CouchDB 2.0:
{code}
{
"dbname": "aiocouchdb/1837f0420b9443f79b039b0aec01c7b2",
"type": "deleted",
"account": "test",
"seq": [
1,
"g1FxeJzLYWBg4MhgTmHgz8tPSTV2MDQy1zMAQsMcoARTIkOS_P___7MymBMZc4EC7MnGqeaWpoaYynEakaQAJJPsQaYkMsBVGaKrcgCpigfbBbQVbJdlmlGSkWkqbpMTQHrq0UxGV5XHAiQZGoAUUOF8wioXQFTuR1ZphFXlAYjK-4RVPoCoBLkzCwD71WBR"
]
}
{code}
In CouchDB 1.6.1:
{code}
{
"type": "updated",
"db_name": "test/aiocouchdb/0e6b5cb3b2e94376b0ecd6ec918e9704"
}
{code}
Breaking changes:
- db_name vs dbname
- dbname doesn't contains full database name because first segment of slashed
name goes to account field
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2666) Degradation: inproper local database name escape on /_replicate
Alexander Shorin created COUCHDB-2666:
-
Summary: Degradation: inproper local database name escape on
/_replicate
Key: COUCHDB-2666
URL: https://issues.apache.org/jira/browse/COUCHDB-2666
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: HTTP Interface, Replication
Reporter: Alexander Shorin
{code}
$ curl -XPUT http://localhost:15984/foo%2fbar
{"ok":true}
$ curl -XPOST http://localhost:15984/_replicate -d '{"source": "foo/bar",
"target": "baz", "create_target": true}' -H "Content-Type: application/json"
{"error":"db_not_found","reason":"could not open
http://127.0.0.1:15984/foo/bar/"}
{code}
Meanwhile in 1.6.1:
{code}
$ curl -XPUT http://localhost:5984/foo%2fbar
{"ok":true}
$ curl -XPOST http://localhost:5984/_replicate -d '{"source": "foo/bar",
"target": "baz", "create_target": true}' -H "Content-Type: application/json"
{"ok":true,"no_changes":true}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2665) Degradation: /_db_updates lost eventsource feed support
Alexander Shorin created COUCHDB-2665:
-
Summary: Degradation: /_db_updates lost eventsource feed support
Key: COUCHDB-2665
URL: https://issues.apache.org/jira/browse/COUCHDB-2665
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Database Core, HTTP Interface
Reporter: Alexander Shorin
{code}
2015-04-18 15:18:18.434 [debug] node1@127.0.0.1 <0.1811.0> httpd 400 error
response:
{"error":"bad_request","reason":"Supported `feed` types: normal, continuous,
longpoll"}
2015-04-18 15:18:18.435 [notice] node1@127.0.0.1 <0.1811.0> 0305bb11 127.0.0.1
localhost:15984 GET /_db_updates?heartbeat=false&feed=eventsource&timeout=1000
400 ok 2
{code}
Which was
[available|https://github.com/apache/couchdb/blob/1.6.x/src/couch_dbupdates/src/couch_dbupdates_httpd.erl#L50-L55]
in 1.6.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2237) Add a 'live' sugar for 'continuous'
[ https://issues.apache.org/jira/browse/COUCHDB-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497387#comment-14497387 ] Alexander Shorin commented on COUCHDB-2237: --- Good idea. We had already experimental features. One more, as alias for existed one, wouldn't harm too much. > Add a 'live' sugar for 'continuous' > --- > > Key: COUCHDB-2237 > URL: https://issues.apache.org/jira/browse/COUCHDB-2237 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: HTTP Interface >Reporter: Dale Harvey > > With PouchDB we generally try to stick to the same param names as Couch, we > are even changing some we implemented first to be compatible > (https://github.com/pouchdb/pouchdb/issues/2193) > However 'continuous' sucks to type, its confusing to type and spell and > everyone gets it wrong, we still support it but switched to documenting it as > 'live' and life is awesome again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2237) Add a 'live' sugar for 'continuous'
[ https://issues.apache.org/jira/browse/COUCHDB-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497348#comment-14497348 ] Alexander Shorin commented on COUCHDB-2237: --- I agree with Joan here. > Add a 'live' sugar for 'continuous' > --- > > Key: COUCHDB-2237 > URL: https://issues.apache.org/jira/browse/COUCHDB-2237 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: HTTP Interface >Reporter: Dale Harvey > > With PouchDB we generally try to stick to the same param names as Couch, we > are even changing some we implemented first to be compatible > (https://github.com/pouchdb/pouchdb/issues/2193) > However 'continuous' sucks to type, its confusing to type and spell and > everyone gets it wrong, we still support it but switched to documenting it as > 'live' and life is awesome again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2661) Gracefully handle not acceptable methods
Alexander Shorin created COUCHDB-2661:
-
Summary: Gracefully handle not acceptable methods
Key: COUCHDB-2661
URL: https://issues.apache.org/jira/browse/COUCHDB-2661
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: HTTP Interface
Reporter: Alexander Shorin
This is meta issue about to check all the endpoints that they are able to
return 405 for non acceptable method instead of 500 like what `/_membership` is
doing for instance:
{code}
$ http PUT http://localhost:15984/_membership
HTTP/1.1 500 Internal Server Error
Cache-Control: must-revalidate
Content-Length: 70
Content-Type: application/json
Date: Mon, 13 Apr 2015 13:05:48 GMT
Server: CouchDB/2f615da (Erlang OTP/17)
X-Couch-Request-ID: 4fb974cb
X-Couch-Stack-Hash: 2050252024
X-CouchDB-Body-Time: 0
{
"error": "unknown_error",
"reason": "function_clause",
"ref": 2050252024
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2659) CouchDB master failing the PouchDB test suite - live changes
[
https://issues.apache.org/jira/browse/COUCHDB-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491134#comment-14491134
]
Alexander Shorin commented on COUCHDB-2659:
---
The reason why they (errors) happened is that in 313 PR dev/run now ensures
that all system databases: _users, _replicator, _metadata are created.
Previously, they were not available for developers cluster.
If I drop _metadata database, PouchDB test suite for couchdb-master bypasses
these failures. This could be a workaround for PouchDB, but certainly, we found
a bug for CouchDB as I can see.
> CouchDB master failing the PouchDB test suite - live changes
>
>
> Key: COUCHDB-2659
> URL: https://issues.apache.org/jira/browse/COUCHDB-2659
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
>Reporter: Nolan Lawson
>
> See [this comment |
> https://github.com/pouchdb/pouchdb/pull/3722#issuecomment-91571425] for
> details. We have automated tests that pull in the latest CouchDB master
> branch and run the PouchDB test suite against it, and recently our tests
> started failing due to [apache/couchdb#313 |
> https://github.com/apache/couchdb/pull/313]. So I switched back to admin
> party mode, but now it's failing for another reason:
> {quote}
> 1) test.attachments.js-http #3074 live changes():
> Uncaught Database encountered an unknown error
> {quote}
> Instructions for running the PouchDB test suite are in our TESTING.md, it's
> pretty straightforward but basically you just want to point it to any CouchDB
> server like so and run the tests:
> {code}
> BAIL=0 COUCH_HOST=http://localhost:15984 npm test
> {code}
> {{BAIL=0}} will prevent bailing upon the first error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2659) CouchDB master failing the PouchDB test suite - live changes
[
https://issues.apache.org/jira/browse/COUCHDB-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491132#comment-14491132
]
Alexander Shorin commented on COUCHDB-2659:
---
Few more from the logs:
{code}
2015-04-11 17:42:19.817 [notice] node1@127.0.0.1 <0.6105.0> b6d6c1f7 127.0.0.1
localhost:15984 GET /testdb/ 200 ok 4
2015-04-11 17:42:24.814 [error] node1@127.0.0.1 <0.6125.0> req_err(99130004)
timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L180">>,<<"cassim_security:get_security_doc/1
L58">>,<<"cassim_security:get_security/2
L46">>,<<"chttpd_auth_request:db_authorization_check/1
L79">>,<<"chttpd_auth_request:authorize_request/1
L19">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L239">>]
2015-04-11 17:42:24.815 [error] node1@127.0.0.1 <0.6125.0> httpd 500 error
response:
{"error":"timeout","reason":"The request could not be processed in a
reasonable amount of time.","ref":99130004}
2015-04-11 17:42:24.824 [notice] node1@127.0.0.1 <0.6125.0> d1b6a0f1 127.0.0.1
localhost:15984 GET
/testdb/_changes?timeout=25000&include_docs=true&attachments=true&feed=longpoll&since=0&limit=25
500 ok 5007
2015-04-11 17:42:31.833 [notice] node1@127.0.0.1 <0.9155.0> b5785fa5 127.0.0.1
localhost:15984 GET /testdb/ 200 ok 10
2015-04-11 17:42:36.827 [error] node1@127.0.0.1 <0.9162.0> req_err(99130004)
timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L180">>,<<"cassim_security:get_security_doc/1
L58">>,<<"cassim_security:get_security/2
L46">>,<<"chttpd_auth_request:db_authorization_check/1
L79">>,<<"chttpd_auth_request:authorize_request/1
L19">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L239">>]
2015-04-11 17:42:36.828 [error] node1@127.0.0.1 <0.9162.0> httpd 500 error
response:
{"error":"timeout","reason":"The request could not be processed in a
reasonable amount of time.","ref":99130004}
2015-04-11 17:42:36.839 [notice] node1@127.0.0.1 <0.9162.0> e7142eda 127.0.0.1
localhost:15984 GET
/testdb/_changes?timeout=25000&feed=longpoll&since=0&limit=25 500 ok 5008
2015-04-11 17:42:36.839 [error] node1@127.0.0.1 <0.9169.0> req_err(99130004)
timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L180">>,<<"cassim_security:get_security_doc/1
L58">>,<<"cassim_security:get_security/2
L46">>,<<"chttpd_auth_request:db_authorization_check/1
L79">>,<<"chttpd_auth_request:authorize_request/1
L19">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L239">>]
2015-04-11 17:42:36.840 [error] node1@127.0.0.1 <0.9169.0> httpd 500 error
response:
{"error":"timeout","reason":"The request could not be processed in a
reasonable amount of time.","ref":99130004}
2015-04-11 17:42:36.845 [notice] node1@127.0.0.1 <0.9169.0> 09b122c6 127.0.0.1
localhost:15984 PUT /testdb/anotherdoc2/mytext 500 ok 5020
2015-04-11 17:42:36.970 [notice] node1@127.0.0.1 <0.9270.0> 5ab519c4 127.0.0.1
localhost:15984 GET /testdb/ 200 ok 7
2015-04-11 17:42:41.965 [error] node1@127.0.0.1 <0.9272.0> req_err(99130004)
timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L180">>,<<"cassim_security:get_security_doc/1
L58">>,<<"cassim_security:get_security/2
L46">>,<<"chttpd_auth_request:db_authorization_check/1
L79">>,<<"chttpd_auth_request:authorize_request/1
L19">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L239">>]
2015-04-11 17:42:41.965 [error] node1@127.0.0.1 <0.9272.0> httpd 500 error
response:
{"error":"timeout","reason":"The request could not be processed in a
reasonable amount of time.","ref":99130004}
2015-04-11 17:42:41.974 [notice] node1@127.0.0.1 <0.9272.0> 3256c30f 127.0.0.1
localhost:15984 GET
/testdb/_changes?timeout=25000&include_docs=true&feed=longpoll&since=[1,%22g1FDeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MSGXAqSVIAkkn2hFQ5gFTFE1KVAFJVT0BVHguQZGgAUkCF8wmrXABRuZ-wygMQlfcJq3wAUQl0J2MWAB5TVnc%22]&limit=25
500 ok 5010
2015-04-11 17:42:41.979 [error] node1@127.0.0.1 <0.9315.0> req_err(99130004)
timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L180">>,<<"cassim_security:get_security_doc/1
L58">>,<<"cassim_security:get_security/2
L46">>,<<"chttpd_auth_request:db_authorization_check/1
L79">>,<<"chttpd_auth_request:authorize_request/1
L19">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L239">>]
2015-04-11 17:42:41.979 [error] node1@127.0.0.1 <0.9315.0> httpd 500 error
response:
{"error":"timeout","reason":"The request could not be processed in a
reasonable amount of time.","ref":99130004}
[jira] [Commented] (COUCHDB-2659) CouchDB master failing the PouchDB test suite - live changes
[
https://issues.apache.org/jira/browse/COUCHDB-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491129#comment-14491129
]
Alexander Shorin commented on COUCHDB-2659:
---
The error that caused this fall:
{code}
2015-04-11 17:42:25.030 [notice] node1@127.0.0.1 <0.6424.0> 672baff8 127.0.0.1
localhost:15984 GET /testdb/ 200 ok 5
2015-04-11 17:42:30.027 [error] node1@127.0.0.1 <0.6425.0> req_err(99130004)
timeout : The request could not be processed in a reasonable amount of time.
[<<"gen_server:call/2 L180">>,<<"cassim_security:get_security_doc/1
L58">>,<<"cassim_security:get_security/2
L46">>,<<"chttpd_auth_request:db_authorization_check/1
L79">>,<<"chttpd_auth_request:authorize_request/1
L19">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L239">>]
2015-04-11 17:42:30.027 [error] node1@127.0.0.1 <0.6425.0> httpd 500 error
response:
{"error":"timeout","reason":"The request could not be processed in a
reasonable amount of time.","ref":99130004}
2015-04-11 17:42:30.037 [notice] node1@127.0.0.1 <0.6425.0> bbfd61c0 127.0.0.1
localhost:15984 GET
/testdb/_changes?timeout=25000&include_docs=true&attachments=true&feed=longpoll&since=0&limit=25
500 ok 5011
{code}
> CouchDB master failing the PouchDB test suite - live changes
>
>
> Key: COUCHDB-2659
> URL: https://issues.apache.org/jira/browse/COUCHDB-2659
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
>Reporter: Nolan Lawson
>
> See [this comment |
> https://github.com/pouchdb/pouchdb/pull/3722#issuecomment-91571425] for
> details. We have automated tests that pull in the latest CouchDB master
> branch and run the PouchDB test suite against it, and recently our tests
> started failing due to [apache/couchdb#313 |
> https://github.com/apache/couchdb/pull/313]. So I switched back to admin
> party mode, but now it's failing for another reason:
> {quote}
> 1) test.attachments.js-http #3074 live changes():
> Uncaught Database encountered an unknown error
> {quote}
> Instructions for running the PouchDB test suite are in our TESTING.md, it's
> pretty straightforward but basically you just want to point it to any CouchDB
> server like so and run the tests:
> {code}
> BAIL=0 COUCH_HOST=http://localhost:15984 npm test
> {code}
> {{BAIL=0}} will prevent bailing upon the first error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2510) Apply system db before_doc_update functions in fabric
[ https://issues.apache.org/jira/browse/COUCHDB-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2510. --- Resolution: Fixed Fix Version/s: 2.0.0 > Apply system db before_doc_update functions in fabric > - > > Key: COUCHDB-2510 > URL: https://issues.apache.org/jira/browse/COUCHDB-2510 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Database Core >Reporter: Paul Joseph Davis >Assignee: Paul Joseph Davis > Fix For: 2.0.0 > > > This is mostly for the users db because it makes random changes to the user > documents before writing them to disk. In a cluster this is a guarantee that > we'll end up with three conflicts each time a user updates their password. > This just hardcodes the two system databases into fabric's doc update handler > the same as they're hard coded in couch_server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2630) Clustered _users is broken
[
https://issues.apache.org/jira/browse/COUCHDB-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin resolved COUCHDB-2630.
---
Resolution: Fixed
Assignee: Robert Newson
> Clustered _users is broken
> --
>
> Key: COUCHDB-2630
> URL: https://issues.apache.org/jira/browse/COUCHDB-2630
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Assignee: Robert Newson
>Priority: Blocker
> Fix For: 2.0.0
>
>
> On attempt to create a new user:
> {code}
> 2015-02-26 22:59:41.090 [error] node1@127.0.0.1 <0.385.0> req_err(4102877184)
> unknown_error : undef
> [<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
> L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> {code}
> Also the _design/_auth document doesn't appears in this database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2632) Clustered _replicator is broken
[
https://issues.apache.org/jira/browse/COUCHDB-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin resolved COUCHDB-2632.
---
Resolution: Fixed
Assignee: Robert Newson
> Clustered _replicator is broken
> ---
>
> Key: COUCHDB-2632
> URL: https://issues.apache.org/jira/browse/COUCHDB-2632
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Assignee: Robert Newson
>Priority: Blocker
> Fix For: 2.0.0
>
>
> On attempt to create a new document:
> {code}
> 2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> req_err(4102877184)
> unknown_error : undef
> [<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
> L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> 2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"undef","ref":4102877184}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2643) fabric_doc_update:before_doc_update is broken
[ https://issues.apache.org/jira/browse/COUCHDB-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2643. --- Resolution: Fixed Fix Version/s: 2.0.0 Assignee: Robert Newson > fabric_doc_update:before_doc_update is broken > - > > Key: COUCHDB-2643 > URL: https://issues.apache.org/jira/browse/COUCHDB-2643 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Database Core >Reporter: ILYA >Assignee: Robert Newson > Fix For: 2.0.0 > > > There are no arity one functions in couch_users_db and > couch_replicator_manager which are called from here > https://github.com/apache/couchdb-fabric/blob/master/src/fabric_doc_update.erl#L104:L106 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2547) Fix broken tests for couch app
[ https://issues.apache.org/jira/browse/COUCHDB-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481188#comment-14481188 ] Alexander Shorin commented on COUCHDB-2547: --- Oh, I miss this one. Will check 6 hours later. > Fix broken tests for couch app > -- > > Key: COUCHDB-2547 > URL: https://issues.apache.org/jira/browse/COUCHDB-2547 > Project: CouchDB > Issue Type: Test > Security Level: public(Regular issues) >Reporter: ILYA >Assignee: ILYA > Fix For: 2.0.0 > > > Some of the tests suites are disabled with -ifdef(run_broken_tests). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2547) Fix broken tests for couch app
[ https://issues.apache.org/jira/browse/COUCHDB-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2547. --- Resolution: Fixed Fix Version/s: 2.0.0 > Fix broken tests for couch app > -- > > Key: COUCHDB-2547 > URL: https://issues.apache.org/jira/browse/COUCHDB-2547 > Project: CouchDB > Issue Type: Test > Security Level: public(Regular issues) >Reporter: ILYA >Assignee: ILYA > Fix For: 2.0.0 > > > Some of the tests suites are disabled with -ifdef(run_broken_tests). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2594) Single node mode: remove warning
[ https://issues.apache.org/jira/browse/COUCHDB-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395931#comment-14395931 ] Alexander Shorin commented on COUCHDB-2594: --- Technically, yes, but will you remember to update this N to proper value when you'll going to join this node to the cluster? Also, there was mentioned that N cannot be changed for existed nodes once it was applied (correct me here if I'm wrong). > Single node mode: remove warning > > > Key: COUCHDB-2594 > URL: https://issues.apache.org/jira/browse/COUCHDB-2594 > Project: CouchDB > Issue Type: Task > Security Level: public(Regular issues) > Components: Database Core >Reporter: Robert Kowalski >Priority: Blocker > Fix For: 2.0.0 > > > we have to remove a warning that is sent as response if the node is not > joined into a multi-node cluster and has no membership -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2237) Add a 'live' sugar for 'continuous'
[ https://issues.apache.org/jira/browse/COUCHDB-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395734#comment-14395734 ] Alexander Shorin commented on COUCHDB-2237: --- In term of breaking compatibility changes, if we really want to drop "continuous" in favour of "stream" or whatever we cannot make it on next major release because of one simple reason: migration. Replication is the way to do that. So it could be only possible to drop it at least at N+2 major release: if it becomes introduced in 2.0, only in 4.0 it could be possible to make alias as primary one. Otherwise migration from 2.x to 3.x would be full of pain. Following this plan, N+1 major release (3.x) need to probe both feed types, preferring new one. > Add a 'live' sugar for 'continuous' > --- > > Key: COUCHDB-2237 > URL: https://issues.apache.org/jira/browse/COUCHDB-2237 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: HTTP Interface >Reporter: Dale Harvey > > With PouchDB we generally try to stick to the same param names as Couch, we > are even changing some we implemented first to be compatible > (https://github.com/pouchdb/pouchdb/issues/2193) > However 'continuous' sucks to type, its confusing to type and spell and > everyone gets it wrong, we still support it but switched to documenting it as > 'live' and life is awesome again -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2588) dereferencing type-punned pointer will break strict-aliasing rule
[
https://issues.apache.org/jira/browse/COUCHDB-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395719#comment-14395719
]
Alexander Shorin commented on COUCHDB-2588:
---
Was easy to fix without disabling that warning, but I wonder if that is correct
and what the intentions were for original implementation:
https://github.com/apache/couchdb-b64url/pull/2
https://github.com/apache/couchdb-khash/pull/1
But so far it works and compiles fine.
> dereferencing type-punned pointer will break strict-aliasing rule
> -
>
> Key: COUCHDB-2588
> URL: https://issues.apache.org/jira/browse/COUCHDB-2588
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
>Affects Versions: 2.0.0
> Environment: FreeBSD 9
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> Happens on FreeBSD 9:
> {code}
> # gcc -v
> Using built-in specs.
> Target: i386-undermydesk-freebsd
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 4.2.1 20070831 patched [FreeBSD]
> ==> b64url (compile)
> Compiled src/b64url.erl
> Compiling /root/couchdb/src/b64url/c_src/b64url.c
> cc1: warnings being treated as errors
> /root/couchdb/src/b64url/c_src/b64url.c: In function 'b64url_encode_cont':
> /root/couchdb/src/b64url/c_src/b64url.c:424: warning: dereferencing
> type-punned pointer will break strict-aliasing rules
> /root/couchdb/src/b64url/c_src/b64url.c: In function 'b64url_decode_cont':
> /root/couchdb/src/b64url/c_src/b64url.c:579: warning: dereferencing
> type-punned pointer will break strict-aliasing rules
> ERROR: compile failed while processing /root/couchdb/src/b64url: rebar_abort
> *** [couch] Error code 1
> ==> khash (compile)
> Compiled src/khash.erl
> Compiling c_src/hash.c
> Compiling /root/couchdb/src/khash/c_src/khash.c
> cc1: warnings being treated as errors
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_to_list':
> /root/couchdb/src/khash/c_src/khash.c:232: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_clear':
> /root/couchdb/src/khash/c_src/khash.c:264: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_lookup':
> /root/couchdb/src/khash/c_src/khash.c:303: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_get':
> /root/couchdb/src/khash/c_src/khash.c:337: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_put':
> /root/couchdb/src/khash/c_src/khash.c:369: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_del':
> /root/couchdb/src/khash/c_src/khash.c:409: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_size':
> /root/couchdb/src/khash/c_src/khash.c:441: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_iter':
> /root/couchdb/src/khash/c_src/khash.c:465: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> /root/couchdb/src/khash/c_src/khash.c: In function 'khash_iter_next':
> /root/couchdb/src/khash/c_src/khash.c:514: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
> ERROR: compile failed while processing /root/couchdb/src/khash: rebar_abort
> *** [couch] Error code 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2615) Ensure that rebar exists and his version is correct
[ https://issues.apache.org/jira/browse/COUCHDB-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14388202#comment-14388202 ] Alexander Shorin commented on COUCHDB-2615: --- [We have it](https://github.com/apache/couchdb/blob/master/README-DEV#L17), however more exact specification that works now would be >=2.3.1 and <3.0. > Ensure that rebar exists and his version is correct > --- > > Key: COUCHDB-2615 > URL: https://issues.apache.org/jira/browse/COUCHDB-2615 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Build System >Reporter: Alexander Shorin >Priority: Blocker > Fix For: 2.0.0 > > > Currently, we relay on the fact that rebar is installed somehow in the system > before user runs ./configure. This causes the following issues: > - rebar may actually not being available > - rebar version may be too old > To avoid these issues and make install process more "relaxed", on ./configure > phare we could build rebar before fetch any dependencies. Hopefully, we have > [own fork|https://git-wip-us.apache.org/repos/asf?p=couchdb-rebar.git] to not > depend on remote upstream. > However, it's not wise to always build our own rebar on ./configure - on the > end user system there could be already installed rebar with the right > version. For this case, we need to provide a switch flag like > --with-system-rebar for ./configure script which check if the system rebar > version is correct (iirc, we need 2.3.1+, but need to double check that). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2163) Visualize document revision tree and navigate between these revisions
[ https://issues.apache.org/jira/browse/COUCHDB-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382014#comment-14382014 ] Alexander Shorin commented on COUCHDB-2163: --- [~nolanlawson] looks amazing! > Visualize document revision tree and navigate between these revisions > - > > Key: COUCHDB-2163 > URL: https://issues.apache.org/jira/browse/COUCHDB-2163 > Project: CouchDB > Issue Type: New Feature > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin > Labels: CouchDB, gsoc2015, javascript > > Futon allows just to navigate between revisions on the same branch. > It would be awesome if Fauxton will visualize revision tree like > [visualizeRevTree|https://github.com/neojski/visualizeRevTree] does and > allows to jump to the specific revision in single click. > Currently Fauxton only shows the "latest" document's revision with no > "history" navigation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2648) Rev tree visualization in Fauxton
[ https://issues.apache.org/jira/browse/COUCHDB-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382012#comment-14382012 ] Alexander Shorin commented on COUCHDB-2648: --- Google Summer of Code. [~nadeeshaan] is on it. > Rev tree visualization in Fauxton > - > > Key: COUCHDB-2648 > URL: https://issues.apache.org/jira/browse/COUCHDB-2648 > Project: CouchDB > Issue Type: New Feature > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Nolan Lawson > > If a feature isn't visible, then it doesn't exist, from the point of view of > users. I would posit that the reason people don't make much use of conflict > resolution is that they have no idea how rev trees work. > Conflict resolution is the killer feature of CouchDB. We really need some way > to visualize that in the interface. > Follow-up to this conversation: > https://twitter.com/daleharvey/status/580725036555870208 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2648) Rev tree visualization in Fauxton
[ https://issues.apache.org/jira/browse/COUCHDB-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382006#comment-14382006 ] Alexander Shorin commented on COUCHDB-2648: --- We are already have issue about this feature and it's a part of GSoC (: > Rev tree visualization in Fauxton > - > > Key: COUCHDB-2648 > URL: https://issues.apache.org/jira/browse/COUCHDB-2648 > Project: CouchDB > Issue Type: New Feature > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Nolan Lawson > > If a feature isn't visible, then it doesn't exist, from the point of view of > users. I would posit that the reason people don't make much use of conflict > resolution is that they have no idea how rev trees work. > Conflict resolution is the killer feature of CouchDB. We really need some way > to visualize that in the interface. > Follow-up to this conversation: > https://twitter.com/daleharvey/status/580725036555870208 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (COUCHDB-2648) Rev tree visualization in Fauxton
[ https://issues.apache.org/jira/browse/COUCHDB-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-2648. - Resolution: Duplicate > Rev tree visualization in Fauxton > - > > Key: COUCHDB-2648 > URL: https://issues.apache.org/jira/browse/COUCHDB-2648 > Project: CouchDB > Issue Type: New Feature > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Nolan Lawson > > If a feature isn't visible, then it doesn't exist, from the point of view of > users. I would posit that the reason people don't make much use of conflict > resolution is that they have no idea how rev trees work. > Conflict resolution is the killer feature of CouchDB. We really need some way > to visualize that in the interface. > Follow-up to this conversation: > https://twitter.com/daleharvey/status/580725036555870208 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2422) Cassim and underscored databases
[
https://issues.apache.org/jira/browse/COUCHDB-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin resolved COUCHDB-2422.
---
Resolution: Fixed
Assignee: Alexander Shorin
> Cassim and underscored databases
>
>
> Key: COUCHDB-2422
> URL: https://issues.apache.org/jira/browse/COUCHDB-2422
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Database Core
>Reporter: Alexander Shorin
>Assignee: Alexander Shorin
>
> 1. Run dev cluster
> 2. Create {{_users}} database
> {code}
> http PUT http://localhost:15984/_users
> HTTP/1.1 201 Created
> Cache-Control: must-revalidate
> Content-Length: 12
> Content-Type: text/plain; charset=utf-8
> Date: Fri, 31 Oct 2014 10:36:19 GMT
> Location: http://localhost:15984/_users
> Server: CouchDB/9938fac (Erlang OTP/17)
> X-Couch-Request-ID: f273be89
> X-CouchDB-Body-Time: 0
> {"ok":true}
> {code}
> 3. Create cassim database
> {code}
> http PUT http://localhost:15984/cassim
> HTTP/1.1 201 Created
> Cache-Control: must-revalidate
> Content-Length: 12
> Content-Type: text/plain; charset=utf-8
> Date: Fri, 31 Oct 2014 10:37:06 GMT
> Location: http://localhost:15984/cassim
> Server: CouchDB/9938fac (Erlang OTP/17)
> X-Couch-Request-ID: 8bdcc974
> X-CouchDB-Body-Time: 0
> {"ok":true}
> {code}
> 4. Try to access {{_users}} database:
> {code}
> http http://localhost:15984/_users
> HTTP/1.1 400 Bad Request
> Cache-Control: must-revalidate
> Content-Length: 89
> Content-Type: text/plain; charset=utf-8
> Date: Fri, 31 Oct 2014 10:34:22 GMT
> Server: CouchDB/9938fac (Erlang OTP/17)
> X-Couch-Request-ID: e9f4a5b3
> X-CouchDB-Body-Time: 0
> {"error":"bad_request","reason":"Only reserved document ids may start with
> underscore."}
> {code}
> Oh wait...? This is because cassim creates documents with database name as
> the prefix and for {{_users}} and {{_replicator}} it clashes with
> restrictions about document names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2643) fabric_doc_update:before_doc_update is broken
[ https://issues.apache.org/jira/browse/COUCHDB-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369608#comment-14369608 ] Alexander Shorin commented on COUCHDB-2643: --- COUCHDB-2630 and COUCHDB-2632 are relevant to this issue? > fabric_doc_update:before_doc_update is broken > - > > Key: COUCHDB-2643 > URL: https://issues.apache.org/jira/browse/COUCHDB-2643 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Database Core >Reporter: ILYA > > There are no arity one functions in couch_users_db and > couch_replicator_manager which are called from here > https://github.com/apache/couchdb-fabric/blob/master/src/fabric_doc_update.erl#L104:L106 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2642) Emptly database security names/roles
[ https://issues.apache.org/jira/browse/COUCHDB-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2642: -- Attachment: COUCHDB-2642.png > Emptly database security names/roles > > > Key: COUCHDB-2642 > URL: https://issues.apache.org/jira/browse/COUCHDB-2642 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin > Attachments: COUCHDB-2642.png > > > 1. Open Fauxton > 2. Navigate to some database > 3. Go to Permissions section > 4. Click on Add Role / Add Name without entering anything > 5. Now add some more meaning values and see what happens with the names/roles > list -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2642) Emptly database security names/roles
Alexander Shorin created COUCHDB-2642: - Summary: Emptly database security names/roles Key: COUCHDB-2642 URL: https://issues.apache.org/jira/browse/COUCHDB-2642 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin 1. Open Fauxton 2. Navigate to some database 3. Go to Permissions section 4. Click on Add Role / Add Name without entering anything 5. Now add some more meaning values and see what happens with the names/roles list -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2641) Fresh build of CouchDB 2.0 Developer Preview fails to start - "Could not open file ... nodes.couch"
[
https://issues.apache.org/jira/browse/COUCHDB-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin resolved COUCHDB-2641.
---
Resolution: Fixed
Assignee: Alexander Shorin
Fixed. Please update developers-preview git clone and follow the build process
instructions.
> Fresh build of CouchDB 2.0 Developer Preview fails to start - "Could not open
> file ... nodes.couch"
> ---
>
> Key: COUCHDB-2641
> URL: https://issues.apache.org/jira/browse/COUCHDB-2641
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Glynn Bird
>Assignee: Alexander Shorin
>
> After building CouchDB 2.0 Developer Preview from scratch today and starting
> with:
> dev/run
> or
> dev/run -n 1
> The cluster failed to start. The log files says:
> {Code}
> Headers:
> [{'Accept-Encoding',"identity"},{'Content-Length',"2"},{'Host',"127.0.0.1:15986"}]
> 2015-03-18 09:52:58.497 [debug] node1@127.0.0.1 <0.213.0> OAuth Params: []
> 2015-03-18 09:52:58.500 [error] node1@127.0.0.1 <0.372.0> Could not open file
> /Users/glynnb/projects/couchdb/dev/lib/node1/data/nodes.couch: no such file
> or directory
> 2015-03-18 09:52:58.500 [info] node1@127.0.0.1 <0.203.0> open_result error
> {not_found,no_db_file} for nodes
> 2015-03-18 09:52:58.500 [debug] node1@127.0.0.1 <0.213.0> Minor error in HTTP
> request: {not_found,no_db_file}
> 2015-03-18 09:52:58.501 [debug] node1@127.0.0.1 <0.213.0> Stacktrace:
> [{couch_httpd_db,do_db_req,2,[{file,"src/couch_httpd_db.erl"},{line,248}]},{couch_httpd,handle_request_int,5,[{file,"src/couch_httpd.erl"},{line,301}]},{mochiweb_http,headers,5,[{file,"src/mochiweb_http.erl"},{line,93}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
> 2015-03-18 09:52:58.501 [notice] node1@127.0.0.1 <0.213.0> 127.0.0.1 - - PUT
> /nodes/node1@127.0.0.1 404
> 2015-03-18 09:52:58.501 [debug] node1@127.0.0.1 <0.213.0> httpd 404 error
> response:
> {"error":"not_found","reason":"no_db_file"}
> {Code}
> I fixed it by making symlink to "dev/lib/node1/data/_nodes.couch" called
> "nodes.couch". i.e _nodes.couch exists but nodes.couch does not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2605) Visualize the CouchDB Cluster
[ https://issues.apache.org/jira/browse/COUCHDB-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362852#comment-14362852 ] Alexander Shorin commented on COUCHDB-2605: --- Hm, you seems to have a quite old clone if this error happened. Good to update it, reconfigure and make again to avoid other possible issues. Clean new checkout may be as well helpful. > Visualize the CouchDB Cluster > - > > Key: COUCHDB-2605 > URL: https://issues.apache.org/jira/browse/COUCHDB-2605 > Project: CouchDB > Issue Type: Task > Security Level: public(Regular issues) > Components: Fauxton >Affects Versions: 2.1 >Reporter: Robert Kowalski > Labels: CouchDB, gsoc2015, javascript > > Show for each database on which nodes in the cluster the data is stored - and > warn if the disk space runs out on these nodes. > The project is using React.js for the Admin-Interface. You will use > JavaScript, CSS, HTML and the HTTP API of CouchDB to visualize the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini
[ https://issues.apache.org/jira/browse/COUCHDB-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362397#comment-14362397 ] Alexander Shorin commented on COUCHDB-2638: --- uuid is not only the only what generates on startup: couch_httpd_auth/secret does as well. But even if they are pregenerated, CouchDB wont start since it will still try to open local.ini for write and will fails due to eacces error. > CouchDB should not be writing /etc/couchdb/local.ini > > > Key: COUCHDB-2638 > URL: https://issues.apache.org/jira/browse/COUCHDB-2638 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Yuri > Fix For: 2.0.0 > > > I am getting such messages in log on FreeBSD: > > Could not write config file /usr/local/etc/couchdb/local.ini: permission > > denied > The problem is that CoachDB supplies the original copy of local.ini, and it > is treated as a template for this configuration file. It is placed into > /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into > /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin > configures. Ideally admin can compare local.ini and local.ini.sample and see > if anything in default configuration was modified compared to the suggested > sample. > When the executable itself modifies local.ini too, this makes it very > confusing. Admin will be confused if he should or shouldn't touch this file. > My suggestion is that CouchDB should copy local.ini under /var/db/, or > somewhere else, and write it there. /etc isn't supposed to be writable by the > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini
[ https://issues.apache.org/jira/browse/COUCHDB-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362383#comment-14362383 ] Alexander Shorin commented on COUCHDB-2638: --- [~rnewson] how it suppose to run CouchDB with readonly /etc | /usr/local/etc then? I think there is a sense to not require write bit for config files, but not in the way [~yurivict] proposed. > CouchDB should not be writing /etc/couchdb/local.ini > > > Key: COUCHDB-2638 > URL: https://issues.apache.org/jira/browse/COUCHDB-2638 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Yuri > Fix For: 2.0.0 > > > I am getting such messages in log on FreeBSD: > > Could not write config file /usr/local/etc/couchdb/local.ini: permission > > denied > The problem is that CoachDB supplies the original copy of local.ini, and it > is treated as a template for this configuration file. It is placed into > /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into > /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin > configures. Ideally admin can compare local.ini and local.ini.sample and see > if anything in default configuration was modified compared to the suggested > sample. > When the executable itself modifies local.ini too, this makes it very > confusing. Admin will be confused if he should or shouldn't touch this file. > My suggestion is that CouchDB should copy local.ini under /var/db/, or > somewhere else, and write it there. /etc isn't supposed to be writable by the > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2605) Visualize the CouchDB Cluster
[ https://issues.apache.org/jira/browse/COUCHDB-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362362#comment-14362362 ] Alexander Shorin commented on COUCHDB-2605: --- [~Udantha] anything interesting in dev/logs/* ? > Visualize the CouchDB Cluster > - > > Key: COUCHDB-2605 > URL: https://issues.apache.org/jira/browse/COUCHDB-2605 > Project: CouchDB > Issue Type: Task > Security Level: public(Regular issues) > Components: Fauxton >Affects Versions: 2.1 >Reporter: Robert Kowalski > Labels: CouchDB, gsoc2015, javascript > > Show for each database on which nodes in the cluster the data is stored - and > warn if the disk space runs out on these nodes. > The project is using React.js for the Admin-Interface. You will use > JavaScript, CSS, HTML and the HTTP API of CouchDB to visualize the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini
[ https://issues.apache.org/jira/browse/COUCHDB-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362345#comment-14362345 ] Alexander Shorin commented on COUCHDB-2638: --- Well, this isn't a workaround, but an installation requirement. Most of other services are as well requires to restart after manual config file edit or provides similar API to change/reload config without stop. The reload feature comes with 2.0 release and with it read-only for CouchDB process configuration makes a sense. As for 1.x, those admins have to continuously restart a server after config update or use /_config API to apply every changes on the fly. Pretty sure they'll pick the second way. Anyway, that's bikeshedding topic. I'll recommend to keep this issue open to prove that CouchDB 2.0 is able to work with read-only configs and able to reload them while gracefully handle eaccess errors. As for 1.x there is nothing to do. > CouchDB should not be writing /etc/couchdb/local.ini > > > Key: COUCHDB-2638 > URL: https://issues.apache.org/jira/browse/COUCHDB-2638 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Yuri > Fix For: 2.0.0 > > > I am getting such messages in log on FreeBSD: > > Could not write config file /usr/local/etc/couchdb/local.ini: permission > > denied > The problem is that CoachDB supplies the original copy of local.ini, and it > is treated as a template for this configuration file. It is placed into > /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into > /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin > configures. Ideally admin can compare local.ini and local.ini.sample and see > if anything in default configuration was modified compared to the suggested > sample. > When the executable itself modifies local.ini too, this makes it very > confusing. Admin will be confused if he should or shouldn't touch this file. > My suggestion is that CouchDB should copy local.ini under /var/db/, or > somewhere else, and write it there. /etc isn't supposed to be writable by the > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini
[ https://issues.apache.org/jira/browse/COUCHDB-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2638: -- Fix Version/s: 2.0.0 > CouchDB should not be writing /etc/couchdb/local.ini > > > Key: COUCHDB-2638 > URL: https://issues.apache.org/jira/browse/COUCHDB-2638 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Yuri > Fix For: 2.0.0 > > > I am getting such messages in log on FreeBSD: > > Could not write config file /usr/local/etc/couchdb/local.ini: permission > > denied > The problem is that CoachDB supplies the original copy of local.ini, and it > is treated as a template for this configuration file. It is placed into > /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into > /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin > configures. Ideally admin can compare local.ini and local.ini.sample and see > if anything in default configuration was modified compared to the suggested > sample. > When the executable itself modifies local.ini too, this makes it very > confusing. Admin will be confused if he should or shouldn't touch this file. > My suggestion is that CouchDB should copy local.ini under /var/db/, or > somewhere else, and write it there. /etc isn't supposed to be writable by the > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini
[ https://issues.apache.org/jira/browse/COUCHDB-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362336#comment-14362336 ] Alexander Shorin commented on COUCHDB-2638: --- First, admin shouldn't edit config file manually often: CouchDB provides API to operate with config file (which is admin-only operation as well). Second, in this case admin's changes won't be applied on live instance - you'll have to restart it. Using API doesn't requires to restart a service to apply the changes. Data may get lost only in case of concurrent edition of the same section and key in config file. But here last wons. That's not an issue. > CouchDB should not be writing /etc/couchdb/local.ini > > > Key: COUCHDB-2638 > URL: https://issues.apache.org/jira/browse/COUCHDB-2638 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Yuri > > I am getting such messages in log on FreeBSD: > > Could not write config file /usr/local/etc/couchdb/local.ini: permission > > denied > The problem is that CoachDB supplies the original copy of local.ini, and it > is treated as a template for this configuration file. It is placed into > /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into > /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin > configures. Ideally admin can compare local.ini and local.ini.sample and see > if anything in default configuration was modified compared to the suggested > sample. > When the executable itself modifies local.ini too, this makes it very > confusing. Admin will be confused if he should or shouldn't touch this file. > My suggestion is that CouchDB should copy local.ini under /var/db/, or > somewhere else, and write it there. /etc isn't supposed to be writable by the > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2638) CouchDB should not be writing /etc/couchdb/local.ini
[ https://issues.apache.org/jira/browse/COUCHDB-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362332#comment-14362332 ] Alexander Shorin commented on COUCHDB-2638: --- Setting correct permissions for the config files is a part of installation process. Once it done right, there shouldn't be any permission deny issues. And /var/db or somewhere else isn't a place where configuration files could be ever searched for since /etc and /usr/local/etc is the traditional place for them. > CouchDB should not be writing /etc/couchdb/local.ini > > > Key: COUCHDB-2638 > URL: https://issues.apache.org/jira/browse/COUCHDB-2638 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Yuri > > I am getting such messages in log on FreeBSD: > > Could not write config file /usr/local/etc/couchdb/local.ini: permission > > denied > The problem is that CoachDB supplies the original copy of local.ini, and it > is treated as a template for this configuration file. It is placed into > /usr/local/etc/couchdb/local.ini.sample, and its copy is placed into > /usr/local/etc/couchdb/local.ini. Everything under /etc is what admin > configures. Ideally admin can compare local.ini and local.ini.sample and see > if anything in default configuration was modified compared to the suggested > sample. > When the executable itself modifies local.ini too, this makes it very > confusing. Admin will be confused if he should or shouldn't touch this file. > My suggestion is that CouchDB should copy local.ini under /var/db/, or > somewhere else, and write it there. /etc isn't supposed to be writable by the > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2310) Add a bulk API for revs & open_revs
[
https://issues.apache.org/jira/browse/COUCHDB-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358602#comment-14358602
]
Alexander Shorin commented on COUCHDB-2310:
---
[~janl] ok, have nothing against that.
> Add a bulk API for revs & open_revs
> ---
>
> Key: COUCHDB-2310
> URL: https://issues.apache.org/jira/browse/COUCHDB-2310
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: HTTP Interface
>Reporter: Nolan Lawson
>
> CouchDB replication is too slow.
> And what makes it so slow is that it's just so unnecessarily chatty. During
> replication, you have to do a separate GET for each individual document, in
> order to get the full {{_revisions}} object for that document (using the
> {{revs}} and {{open_revs}} parameters – refer to [the TouchDB
> writeup|https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm]
> or [Benoit's writeup|http://dataprotocols.org/couchdb-replication/] if you
> need a refresher).
> So for example, let's say you've got a database full of 10,000 documents, and
> you replicate using a batch size of 500 (batch sizes are configurable in
> PouchDB). The conversation for a single batch basically looks like this:
> {code}
> - REPLICATOR: gimme 500 changes since seq X (1 GET request)
> - SOURCE: okay
> - REPLICATOR: gimme the _revs_diff for these 500 docs/_revs (1 POST request)
> - SOURCE: okay
> - repeat 500 times:
> - REPLICATOR: gimme the _revisions for doc n with _revs [...] (1 GET
> request)
> - SOURCE: okay
> - REPLICATOR: here's a _bulk_docs with 500 documents (1 POST request)
> - TARGET: okay
> {code}
> See the problem here? That 500-loop, where we have to do a GET for each one
> of 500 documents, is a lot of unnecessary back-and-forth, considering that
> the replicator already knows what it needs before the loop starts. You can
> parallelize, but if you assume a browser (e.g. for PouchDB), most browsers
> only let you do ~8 simultaneous requests at once. Plus, there's latency and
> HTTP headers to consider. So overall, it's not cool.
> So why do we even need to do the separate requests? Shouldn't {{_all_docs}}
> be good enough? Turns out it's not, because we need this special
> {{_revisions}} object.
> For example, consider a document {{'foo'}} with 10 revisions. You may compact
> the database, in which case revisions {{1-x}} through {{9-x}} are no longer
> retrievable. However, if you query using {{revs}} and {{open_revs}}, those
> rev IDs are still available:
> {code}
> $ curl 'http://nolan.iriscouch.com/test/foo?revs=true&open_revs=all'
> {
> "_id": "foo",
> "_rev": "10-c78e199ad5e996b240c9d6482907088e",
> "_revisions": {
> "start": 10,
> "ids": [
> "c78e199ad5e996b240c9d6482907088e",
> "f560283f1968a05046f0c38e468006bb",
> "0091198554171c632c27c8342ddec5af",
> "e0a023e2ea59db73f812ad773ea08b17",
> "65d7f8b8206a244035edd9f252f206ad",
> "069d1432a003c58bdd23f01ff80b718f",
> "d21f26bb604b7fe9eba03ce4562cf37b",
> "31d380f99a6e54875855e1c24469622d",
> "3b4791360024426eadafe31542a2c34b",
> "967a00dff5e02add41819138abb3284d"
> ]
> }
> }
> {code}
> And in the replication algorithm, _this full \_revisions object is required_
> at the point when you copy the document from one database to another, which
> is accomplished with a POST to {{_bulk_docs}} using {{new_edits=false}}. If
> you don't have the full {{_revisions}} object, CouchDB accepts the new
> revision, but considers it to be a conflict. (The exception is with
> generation-1 documents, since they have no history, so as it says in the
> TouchDB writeup, you can safely just use {{_all_docs}} as an optimization for
> such documents.)
> And unfortunately, this {{_revision}} object is only available from the {{GET
> /:dbid/:docid}} endpoint. Trust me; I've tried the other APIs. You can't get
> it anywhere else.
> This is a huge problem, especially in PouchDB where we often have to deal
> with CORS, meaning the number of HTTP requests is doubled. So for those 500
> GETs, it's an extra 500 OPTIONs, which is just unacceptable.
> Replication does not have to be slow. While we were experimenting with ways
> of fetching documents in bulk, we tried a technique that just relied on using
> {{_changes}} with {{include_docs=true}}
> ([|\#2472|https://github.com/pouchdb/pouchdb/pull/2472]). This pushed
> conflicts into the target database, but on the upside, you can sync ~95k
> documents from npm's skimdb repository to the browser in less than 20
> minutes! (See [npm-browser.com|http://npm-browser.com] for a demo.)
> What an amazing story we could tell about the beauty of CouchDB replication,
> if only this trick actually worked!
> My proposal is a simpl
[jira] [Commented] (COUCHDB-2310) Add a bulk API for revs & open_revs
[
https://issues.apache.org/jira/browse/COUCHDB-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358555#comment-14358555
]
Alexander Shorin commented on COUCHDB-2310:
---
[~janl] Is there a reason to add `_bulk_get` to CouchDB just in order to
immediately deprecate it in favour of `_bulk_revs`? If we all agreed on having
`_bulk_revs`, then with CouchDB 2.0 release we'll provide it and only. And
since there is quite some time to let this release happens, PouchDB / Couchbase
/ other folks may deprecate `_bulk_get` on their side only and provide
CouchDB-compatible `_bulk_revs` replacement.
> Add a bulk API for revs & open_revs
> ---
>
> Key: COUCHDB-2310
> URL: https://issues.apache.org/jira/browse/COUCHDB-2310
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: HTTP Interface
>Reporter: Nolan Lawson
>
> CouchDB replication is too slow.
> And what makes it so slow is that it's just so unnecessarily chatty. During
> replication, you have to do a separate GET for each individual document, in
> order to get the full {{_revisions}} object for that document (using the
> {{revs}} and {{open_revs}} parameters – refer to [the TouchDB
> writeup|https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm]
> or [Benoit's writeup|http://dataprotocols.org/couchdb-replication/] if you
> need a refresher).
> So for example, let's say you've got a database full of 10,000 documents, and
> you replicate using a batch size of 500 (batch sizes are configurable in
> PouchDB). The conversation for a single batch basically looks like this:
> {code}
> - REPLICATOR: gimme 500 changes since seq X (1 GET request)
> - SOURCE: okay
> - REPLICATOR: gimme the _revs_diff for these 500 docs/_revs (1 POST request)
> - SOURCE: okay
> - repeat 500 times:
> - REPLICATOR: gimme the _revisions for doc n with _revs [...] (1 GET
> request)
> - SOURCE: okay
> - REPLICATOR: here's a _bulk_docs with 500 documents (1 POST request)
> - TARGET: okay
> {code}
> See the problem here? That 500-loop, where we have to do a GET for each one
> of 500 documents, is a lot of unnecessary back-and-forth, considering that
> the replicator already knows what it needs before the loop starts. You can
> parallelize, but if you assume a browser (e.g. for PouchDB), most browsers
> only let you do ~8 simultaneous requests at once. Plus, there's latency and
> HTTP headers to consider. So overall, it's not cool.
> So why do we even need to do the separate requests? Shouldn't {{_all_docs}}
> be good enough? Turns out it's not, because we need this special
> {{_revisions}} object.
> For example, consider a document {{'foo'}} with 10 revisions. You may compact
> the database, in which case revisions {{1-x}} through {{9-x}} are no longer
> retrievable. However, if you query using {{revs}} and {{open_revs}}, those
> rev IDs are still available:
> {code}
> $ curl 'http://nolan.iriscouch.com/test/foo?revs=true&open_revs=all'
> {
> "_id": "foo",
> "_rev": "10-c78e199ad5e996b240c9d6482907088e",
> "_revisions": {
> "start": 10,
> "ids": [
> "c78e199ad5e996b240c9d6482907088e",
> "f560283f1968a05046f0c38e468006bb",
> "0091198554171c632c27c8342ddec5af",
> "e0a023e2ea59db73f812ad773ea08b17",
> "65d7f8b8206a244035edd9f252f206ad",
> "069d1432a003c58bdd23f01ff80b718f",
> "d21f26bb604b7fe9eba03ce4562cf37b",
> "31d380f99a6e54875855e1c24469622d",
> "3b4791360024426eadafe31542a2c34b",
> "967a00dff5e02add41819138abb3284d"
> ]
> }
> }
> {code}
> And in the replication algorithm, _this full \_revisions object is required_
> at the point when you copy the document from one database to another, which
> is accomplished with a POST to {{_bulk_docs}} using {{new_edits=false}}. If
> you don't have the full {{_revisions}} object, CouchDB accepts the new
> revision, but considers it to be a conflict. (The exception is with
> generation-1 documents, since they have no history, so as it says in the
> TouchDB writeup, you can safely just use {{_all_docs}} as an optimization for
> such documents.)
> And unfortunately, this {{_revision}} object is only available from the {{GET
> /:dbid/:docid}} endpoint. Trust me; I've tried the other APIs. You can't get
> it anywhere else.
> This is a huge problem, especially in PouchDB where we often have to deal
> with CORS, meaning the number of HTTP requests is doubled. So for those 500
> GETs, it's an extra 500 OPTIONs, which is just unacceptable.
> Replication does not have to be slow. While we were experimenting with ways
> of fetching documents in bulk, we tried a technique that just relied on using
> {{_changes}} with {{include_docs=true}}
> ([|\#2472|https://github.com/pouchdb/pouch
[jira] [Commented] (COUCHDB-2635) Replace hardcoded list of systems dbs with registration approach
[ https://issues.apache.org/jira/browse/COUCHDB-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355636#comment-14355636 ] Alexander Shorin commented on COUCHDB-2635: --- Imagine you're going to install a new plugin which need to introduce new system database for some own routines. Without patching CouchDB that's not a possible. > Replace hardcoded list of systems dbs with registration approach > > > Key: COUCHDB-2635 > URL: https://issues.apache.org/jira/browse/COUCHDB-2635 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: ILYA >Assignee: ILYA > > To replace this > https://github.com/apache/couchdb-couch/blob/master/include/couch_db.hrl#L43:L49 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2635) Replace hardcoded list of systems dbs with registration approach
[ https://issues.apache.org/jira/browse/COUCHDB-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355631#comment-14355631 ] Alexander Shorin commented on COUCHDB-2635: --- The problem is that to add one more system database you have to edit couch_db.hrl (now, but was couch_db.erl) to add it into special list which allows to apply some special hooks and bypass database validation name in order to create it. This getting worse since fabric have to duplicate a part of this logic in his own code. > Replace hardcoded list of systems dbs with registration approach > > > Key: COUCHDB-2635 > URL: https://issues.apache.org/jira/browse/COUCHDB-2635 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: ILYA >Assignee: ILYA > > To replace this > https://github.com/apache/couchdb-couch/blob/master/include/couch_db.hrl#L43:L49 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2635) Replace hardcoded list of systems dbs with registration approach
[ https://issues.apache.org/jira/browse/COUCHDB-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355617#comment-14355617 ] Alexander Shorin commented on COUCHDB-2635: --- [~janl] the proposed registration is for erlang code side and developers, not for end users. > Replace hardcoded list of systems dbs with registration approach > > > Key: COUCHDB-2635 > URL: https://issues.apache.org/jira/browse/COUCHDB-2635 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: ILYA >Assignee: ILYA > > To replace this > https://github.com/apache/couchdb-couch/blob/master/include/couch_db.hrl#L43:L49 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2178) Normalize templates naming
[
https://issues.apache.org/jira/browse/COUCHDB-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14351799#comment-14351799
]
Alexander Shorin commented on COUCHDB-2178:
---
_stats and _acitve_tasks are also valid CouchDB endpoints, but Fauxton doesn't
provides the feature you say for them.
Another side of this issue is naming style: lower case vs camelCase vs
underscored_lower_case.
> Normalize templates naming
> --
>
> Key: COUCHDB-2178
> URL: https://issues.apache.org/jira/browse/COUCHDB-2178
> Project: CouchDB
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Fauxton
>Reporter: Alexander Shorin
> Labels: beginners
>
> {{_log}} and {{_config}}, but {{stats}} and {{activetasks}}.
> {{verifyinstall}}, but {{createAdmin}}. However, {{database/test/new_view}}.
> I think they should follow some common rule to not confuse people who tries
> to enter the URL manually.
--
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=14343013#comment-14343013
]
Alexander Shorin commented on COUCHDB-2537:
---
Would like to close this as Won't Fix by following reasons:
1. CouchDB 2.0 isn't cluster only. It still may works in single node mode which
is like 1.x, but with more features. And the 1.x use cases are applicable here.
2. There are a lot of cases when knowledge about local_seq is useful. I'll add
one more: start listen changes feed from the point when the specific document
had been changed. Without knowing his seq that turns into iteration over whole
feed with not much of reasons.
3. It seems there are people who uses it. Removing ?local_seq=true will not
actually make our code simpler nor simplify API, but will only hide a part of
system information that could be useful in certain cases. In the end, this
parameter is optional.
What indeed worth to done is the return cluster wide seq (e.g. [1,"abcde"]
instead of just 1) on requesting document on cluster interface. But that's a
question for another issue.
> 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] [Resolved] (COUCHDB-2585) Make admin check extensible in global_change
[ https://issues.apache.org/jira/browse/COUCHDB-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2585. --- Resolution: Fixed > Make admin check extensible in global_change > > > Key: COUCHDB-2585 > URL: https://issues.apache.org/jira/browse/COUCHDB-2585 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: ILYA >Assignee: ILYA > > Currently there is no way to use different user here > https://github.com/apache/couchdb-global-changes/blob/master/src/global_changes_httpd.erl#L46 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2628) Resolve shard(s)_db naming discrepancies
[ https://issues.apache.org/jira/browse/COUCHDB-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2628. --- Resolution: Fixed Fix Version/s: 2.0.0 Assignee: Alexander Shorin > Resolve shard(s)_db naming discrepancies > > > Key: COUCHDB-2628 > URL: https://issues.apache.org/jira/browse/COUCHDB-2628 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: BigCouch >Reporter: Russell Branca >Assignee: Alexander Shorin > Fix For: 2.0.0 > > > Looks like there's a handful of discrepancies where `shard_db` is referenced > rather than `shards_db` which is the version actually used when creating the > relevant database [1]. A quick grep around shows about 8 uses of `shard_db`. > [1] > https://github.com/apache/couchdb-mem3/blob/master/src/mem3_shards.erl#L228-L229 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2620) Rename cassim db to _metadata
[ https://issues.apache.org/jira/browse/COUCHDB-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2620. --- Resolution: Fixed Fix Version/s: 2.0.0 > Rename cassim db to _metadata > - > > Key: COUCHDB-2620 > URL: https://issues.apache.org/jira/browse/COUCHDB-2620 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: Alexander Shorin >Assignee: Alexander Shorin > Fix For: 2.0.0 > > > After IRC conversation with [~janl] and [~chewbranca] we -decided- are > proposing to rename cassim database into something more specific and > concrete. This database currently holds only _security of all cluster > databases, but is designed for more. In future, we could use it to handle > config-per-database feature and etc. The _metadata name reflects nicely such > propose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COUCHDB-2619) Make all system databases start with underscore
[ https://issues.apache.org/jira/browse/COUCHDB-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin resolved COUCHDB-2619. --- Resolution: Fixed Fix Version/s: 2.0.0 > Make all system databases start with underscore > --- > > Key: COUCHDB-2619 > URL: https://issues.apache.org/jira/browse/COUCHDB-2619 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: Alexander Shorin >Assignee: Alexander Shorin > Fix For: 2.0.0 > > > With 2.0 here comes three new system databases: dbs, nodes and cassim. They > need to have underscore in prefix as like as _users and _replicator has to > explicitly denote them from user databases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2632) Clustered _replicator is broken
[
https://issues.apache.org/jira/browse/COUCHDB-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2632:
--
Fix Version/s: 2.0.0
> Clustered _replicator is broken
> ---
>
> Key: COUCHDB-2632
> URL: https://issues.apache.org/jira/browse/COUCHDB-2632
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> On attempt to create a new document:
> {code}
> 2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> req_err(4102877184)
> unknown_error : undef
> [<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
> L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> 2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"undef","ref":4102877184}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2632) Clustered _replicator is broken
[
https://issues.apache.org/jira/browse/COUCHDB-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2632:
--
Priority: Blocker (was: Major)
> Clustered _replicator is broken
> ---
>
> Key: COUCHDB-2632
> URL: https://issues.apache.org/jira/browse/COUCHDB-2632
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> On attempt to create a new document:
> {code}
> 2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> req_err(4102877184)
> unknown_error : undef
> [<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
> L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> 2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"undef","ref":4102877184}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2632) Clustered _replicator is broken
Alexander Shorin created COUCHDB-2632:
-
Summary: Clustered _replicator is broken
Key: COUCHDB-2632
URL: https://issues.apache.org/jira/browse/COUCHDB-2632
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: BigCouch
Reporter: Alexander Shorin
On attempt to create a new document:
{code}
2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> req_err(4102877184)
unknown_error : undef
[<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
2015-02-26 23:09:09.018 [error] node1@127.0.0.1 <0.393.0> httpd 500 error
response:
{"error":"unknown_error","reason":"undef","ref":4102877184}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2630) Clustered _users is broken
[
https://issues.apache.org/jira/browse/COUCHDB-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2630:
--
Priority: Blocker (was: Major)
> Clustered _users is broken
> --
>
> Key: COUCHDB-2630
> URL: https://issues.apache.org/jira/browse/COUCHDB-2630
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> On attempt to create a new user:
> {code}
> 2015-02-26 22:59:41.090 [error] node1@127.0.0.1 <0.385.0> req_err(4102877184)
> unknown_error : undef
> [<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
> L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> {code}
> Also the _design/_auth document doesn't appears in this database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2631) Ensure that system databases callbacks are adds correctly for shared case
[
https://issues.apache.org/jira/browse/COUCHDB-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2631:
--
Fix Version/s: 2.0.0
> Ensure that system databases callbacks are adds correctly for shared case
> -
>
> Key: COUCHDB-2631
> URL: https://issues.apache.org/jira/browse/COUCHDB-2631
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> We have the following code in
> [couch_server|https://github.com/apache/couchdb-couch/blob/master/src/couch_server.erl#L119-L143]
> {code}
> maybe_add_sys_db_callbacks(DbName, Options) when is_binary(DbName) ->
> maybe_add_sys_db_callbacks(?b2l(DbName), Options);
> maybe_add_sys_db_callbacks(DbName, Options) ->
> DbsDbName = config:get("mem3", "shard_db", "dbs"),
> NodesDbName = config:get("mem3", "node_db", "nodes"),
> IsReplicatorDb = DbName == config:get("replicator", "db", "_replicator")
> orelse
> path_ends_with(DbName, <<"_replicator">>),
> IsUsersDb = DbName ==config:get("couch_httpd_auth", "authentication_db",
> "_users") orelse
> path_ends_with(DbName, <<"_users">>),
> if
> DbName == DbsDbName ->
> [sys_db | Options];
> DbName == NodesDbName ->
> [sys_db | Options];
> IsReplicatorDb ->
> [{before_doc_update, fun
> couch_replicator_manager:before_doc_update/2},
>{after_doc_read, fun couch_replicator_manager:after_doc_read/2},
>sys_db | Options];
> IsUsersDb ->
> [{before_doc_update, fun couch_users_db:before_doc_update/2},
>{after_doc_read, fun couch_users_db:after_doc_read/2},
>sys_db | Options];
> true ->
> Options
> end.
> {code}
> Which works perfectly except if system database is clustered. So, for shared
> _users and _replicator the check condition will not work since shared
> databases ends with timestamp and full name looks as
> "shards/-1fff/_users.1424979962"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2631) Ensure that system databases callbacks are adds correctly for shared case
Alexander Shorin created COUCHDB-2631:
-
Summary: Ensure that system databases callbacks are adds correctly
for shared case
Key: COUCHDB-2631
URL: https://issues.apache.org/jira/browse/COUCHDB-2631
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: BigCouch
Reporter: Alexander Shorin
We have the following code in
[couch_server|https://github.com/apache/couchdb-couch/blob/master/src/couch_server.erl#L119-L143]
{code}
maybe_add_sys_db_callbacks(DbName, Options) when is_binary(DbName) ->
maybe_add_sys_db_callbacks(?b2l(DbName), Options);
maybe_add_sys_db_callbacks(DbName, Options) ->
DbsDbName = config:get("mem3", "shard_db", "dbs"),
NodesDbName = config:get("mem3", "node_db", "nodes"),
IsReplicatorDb = DbName == config:get("replicator", "db", "_replicator")
orelse
path_ends_with(DbName, <<"_replicator">>),
IsUsersDb = DbName ==config:get("couch_httpd_auth", "authentication_db",
"_users") orelse
path_ends_with(DbName, <<"_users">>),
if
DbName == DbsDbName ->
[sys_db | Options];
DbName == NodesDbName ->
[sys_db | Options];
IsReplicatorDb ->
[{before_doc_update, fun
couch_replicator_manager:before_doc_update/2},
{after_doc_read, fun couch_replicator_manager:after_doc_read/2},
sys_db | Options];
IsUsersDb ->
[{before_doc_update, fun couch_users_db:before_doc_update/2},
{after_doc_read, fun couch_users_db:after_doc_read/2},
sys_db | Options];
true ->
Options
end.
{code}
Which works perfectly except if system database is clustered. So, for shared
_users and _replicator the check condition will not work since shared databases
ends with timestamp and full name looks as
"shards/-1fff/_users.1424979962"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2631) Ensure that system databases callbacks are adds correctly for shared case
[
https://issues.apache.org/jira/browse/COUCHDB-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2631:
--
Priority: Blocker (was: Major)
> Ensure that system databases callbacks are adds correctly for shared case
> -
>
> Key: COUCHDB-2631
> URL: https://issues.apache.org/jira/browse/COUCHDB-2631
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> We have the following code in
> [couch_server|https://github.com/apache/couchdb-couch/blob/master/src/couch_server.erl#L119-L143]
> {code}
> maybe_add_sys_db_callbacks(DbName, Options) when is_binary(DbName) ->
> maybe_add_sys_db_callbacks(?b2l(DbName), Options);
> maybe_add_sys_db_callbacks(DbName, Options) ->
> DbsDbName = config:get("mem3", "shard_db", "dbs"),
> NodesDbName = config:get("mem3", "node_db", "nodes"),
> IsReplicatorDb = DbName == config:get("replicator", "db", "_replicator")
> orelse
> path_ends_with(DbName, <<"_replicator">>),
> IsUsersDb = DbName ==config:get("couch_httpd_auth", "authentication_db",
> "_users") orelse
> path_ends_with(DbName, <<"_users">>),
> if
> DbName == DbsDbName ->
> [sys_db | Options];
> DbName == NodesDbName ->
> [sys_db | Options];
> IsReplicatorDb ->
> [{before_doc_update, fun
> couch_replicator_manager:before_doc_update/2},
>{after_doc_read, fun couch_replicator_manager:after_doc_read/2},
>sys_db | Options];
> IsUsersDb ->
> [{before_doc_update, fun couch_users_db:before_doc_update/2},
>{after_doc_read, fun couch_users_db:after_doc_read/2},
>sys_db | Options];
> true ->
> Options
> end.
> {code}
> Which works perfectly except if system database is clustered. So, for shared
> _users and _replicator the check condition will not work since shared
> databases ends with timestamp and full name looks as
> "shards/-1fff/_users.1424979962"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2630) Clustered _users is broken
Alexander Shorin created COUCHDB-2630:
-
Summary: Clustered _users is broken
Key: COUCHDB-2630
URL: https://issues.apache.org/jira/browse/COUCHDB-2630
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: BigCouch
Reporter: Alexander Shorin
On attempt to create a new user:
{code}
2015-02-26 22:59:41.090 [error] node1@127.0.0.1 <0.385.0> req_err(4102877184)
unknown_error : undef
[<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
{code}
Also the _design/_auth document doesn't appears in this database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2630) Clustered _users is broken
[
https://issues.apache.org/jira/browse/COUCHDB-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2630:
--
Fix Version/s: 2.0.0
> Clustered _users is broken
> --
>
> Key: COUCHDB-2630
> URL: https://issues.apache.org/jira/browse/COUCHDB-2630
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> On attempt to create a new user:
> {code}
> 2015-02-26 22:59:41.090 [error] node1@127.0.0.1 <0.385.0> req_err(4102877184)
> unknown_error : undef
> [<<"chttpd_db:update_doc/4 L919">>,<<"chttpd_db:send_updated_doc/6
> L883">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> {code}
> Also the _design/_auth document doesn't appears in this database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2628) Resolve shard(s)_db naming discrepancies
[ https://issues.apache.org/jira/browse/COUCHDB-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338874#comment-14338874 ] Alexander Shorin commented on COUCHDB-2628: --- I'm to renaming all shard_db to shards_db and node_db to nodes_db. This is more consistent option name since it includes plural form as like as database name. > Resolve shard(s)_db naming discrepancies > > > Key: COUCHDB-2628 > URL: https://issues.apache.org/jira/browse/COUCHDB-2628 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: BigCouch >Reporter: Russell Branca > > Looks like there's a handful of discrepancies where `shard_db` is referenced > rather than `shards_db` which is the version actually used when creating the > relevant database [1]. A quick grep around shows about 8 uses of `shard_db`. > [1] > https://github.com/apache/couchdb-mem3/blob/master/src/mem3_shards.erl#L228-L229 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2626) Explain N last replication failures
[
https://issues.apache.org/jira/browse/COUCHDB-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2626:
--
Description:
It becomes a quite popular question: "I run a replication for over 9K
documents, but in the end replication says that there was N document writes
failures. How can I get those documents ids and the reason why?". The common
answer is to parse the logs for the errors. Not cool.
The idea is to include into replication stats list of document ids which were
failed to store and the reason why. This could looks like:
{code}
{
"history": [
{
"doc_write_failures": 2,
"doc_write_failures_explained": {
"foo": {
"1-abc": {
"error": "forbidden",
"reason": "bad field bar"
},
"1-cde": {
"error": "forbidden",
"reason": "bad field baz"
}
}
},
"docs_read": 10,
"docs_written": 10,
"end_last_seq": 28,
"end_time": "Sun, 11 Aug 2013 20:38:50 GMT",
"missing_checked": 10,
"missing_found": 10,
"recorded_seq": 28,
"session_id": "142a35854a08e205c47174d91b1f9628",
"start_last_seq": 1,
"start_time": "Sun, 11 Aug 2013 20:38:50 GMT"
}
],
"ok": true,
"replication_id_version": 3,
"session_id": "142a35854a08e205c47174d91b1f9628",
"source_last_seq": 28
}
{code}
E.g. just add a mapping with document ids which is a mapping of revisions to
the error info.
However, we shouldn't collect all the failure explanations - you may easily
have thousands failures because of bug in validate_doc_update function and in
this case checkpoint documents will cause too heavy footprint. To avoid this,
number of stored explanations could be limited by some configurable number,
like 50, and actually keep only these N last failures. This usually enough to
understand the source of problem, fix it and rerun replication.
was:
It becomes a quite popular question: "I run a replication for over 9K
documents, but in the end replication says that there was N document writes
failures. How can I get those documents ids and the reason why?". The common
answer is to parse the logs for the errors. Not cool.
The idea is to include into replication stats list of document ids which were
failed to store and the reason why. This could looks like:
{code}
{
"history": [
{
"doc_write_failures": 2,
"doc_write_failures_explained": {
"foo": {
"1-abc": {
"error": "forbidden",
"reason": "bad field bar"
},
"1-cde": {
"error": "forbidden",
"reason": "bad field baz"
},
}
},
"docs_read": 10,
"docs_written": 10,
"end_last_seq": 28,
"end_time": "Sun, 11 Aug 2013 20:38:50 GMT",
"missing_checked": 10,
"missing_found": 10,
"recorded_seq": 28,
"session_id": "142a35854a08e205c47174d91b1f9628",
"start_last_seq": 1,
"start_time": "Sun, 11 Aug 2013 20:38:50 GMT"
}
],
"ok": true,
"replication_id_version": 3,
"session_id": "142a35854a08e205c47174d91b1f9628",
"source_last_seq": 28
}
{code}
E.g. just add a mapping with document ids which is a mapping of revisions to
the error info.
However, we shouldn't collect all the failure explanations - you may easily
have thousands failures because of bug in validate_doc_update function and in
this case checkpoint documents will cause too heavy footprint. To avoid this,
number of stored explanations could be limited by some configurable number,
like 50, and actually keep only these N last failures. This usually enough to
understand the source of problem, fix it and rerun replication.
> Explain N last replication failures
> ---
>
> Key: COUCHDB-2626
> URL: https://issues.apache.org/jira/browse/COUCHDB-2626
> Project: CouchDB
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Replication
>Reporter: Alexander Shorin
>
> It becomes a quite popular question: "I run a replication for over 9K
> documents, but in the end replication says that there was N document writes
> failures. How can I get those documents ids and the reason why?". The common
> answer is to parse the logs for the errors. Not cool.
> The idea is to include into replication stats list of document ids which were
> failed to store and the
[jira] [Created] (COUCHDB-2626) Explain N last replication failures
Alexander Shorin created COUCHDB-2626:
-
Summary: Explain N last replication failures
Key: COUCHDB-2626
URL: https://issues.apache.org/jira/browse/COUCHDB-2626
Project: CouchDB
Issue Type: Improvement
Security Level: public (Regular issues)
Components: Replication
Reporter: Alexander Shorin
It becomes a quite popular question: "I run a replication for over 9K
documents, but in the end replication says that there was N document writes
failures. How can I get those documents ids and the reason why?". The common
answer is to parse the logs for the errors. Not cool.
The idea is to include into replication stats list of document ids which were
failed to store and the reason why. This could looks like:
{code}
{
"history": [
{
"doc_write_failures": 2,
"doc_write_failures_explained": {
"foo": {
"1-abc": {
"error": "forbidden",
"reason": "bad field bar"
},
"1-cde": {
"error": "forbidden",
"reason": "bad field baz"
},
}
},
"docs_read": 10,
"docs_written": 10,
"end_last_seq": 28,
"end_time": "Sun, 11 Aug 2013 20:38:50 GMT",
"missing_checked": 10,
"missing_found": 10,
"recorded_seq": 28,
"session_id": "142a35854a08e205c47174d91b1f9628",
"start_last_seq": 1,
"start_time": "Sun, 11 Aug 2013 20:38:50 GMT"
}
],
"ok": true,
"replication_id_version": 3,
"session_id": "142a35854a08e205c47174d91b1f9628",
"source_last_seq": 28
}
{code}
E.g. just add a mapping with document ids which is a mapping of revisions to
the error info.
However, we shouldn't collect all the failure explanations - you may easily
have thousands failures because of bug in validate_doc_update function and in
this case checkpoint documents will cause too heavy footprint. To avoid this,
number of stored explanations could be limited by some configurable number,
like 50, and actually keep only these N last failures. This usually enough to
understand the source of problem, fix it and rerun replication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2623) Validate default.ini / local.ini config options
[
https://issues.apache.org/jira/browse/COUCHDB-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2623:
--
Priority: Blocker (was: Major)
> Validate default.ini / local.ini config options
> ---
>
> Key: COUCHDB-2623
> URL: https://issues.apache.org/jira/browse/COUCHDB-2623
> Project: CouchDB
> Issue Type: Task
> Security Level: public(Regular issues)
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> We need to double check our configs to ensure that there are no outdated
> options there and all the present ones are actual to their defaults. For
> instance:
> {code}
> [stats]
> ; rate is in milliseconds
> rate = 1000
> ; sample intervals are in seconds
> samples = [0, 60, 300, 900]
> {code}
> Is not actual anymore since we'd change the stats app, but those might expose
> new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2623) Validate default.ini / local.ini config options
[
https://issues.apache.org/jira/browse/COUCHDB-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2623:
--
Fix Version/s: 2.0.0
> Validate default.ini / local.ini config options
> ---
>
> Key: COUCHDB-2623
> URL: https://issues.apache.org/jira/browse/COUCHDB-2623
> Project: CouchDB
> Issue Type: Task
> Security Level: public(Regular issues)
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> We need to double check our configs to ensure that there are no outdated
> options there and all the present ones are actual to their defaults. For
> instance:
> {code}
> [stats]
> ; rate is in milliseconds
> rate = 1000
> ; sample intervals are in seconds
> samples = [0, 60, 300, 900]
> {code}
> Is not actual anymore since we'd change the stats app, but those might expose
> new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2624) Move configuration options from application environment to ini files
Alexander Shorin created COUCHDB-2624: - Summary: Move configuration options from application environment to ini files Key: COUCHDB-2624 URL: https://issues.apache.org/jira/browse/COUCHDB-2624 Project: CouchDB Issue Type: Task Security Level: public (Regular issues) Reporter: Alexander Shorin We have a lot of interesting configu options which are only defined in application environment and are not available for tweaking by user from configuration file. We need to move those to default.ini and manage them via couchdb-config app. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2623) Validate default.ini / local.ini config options
Alexander Shorin created COUCHDB-2623:
-
Summary: Validate default.ini / local.ini config options
Key: COUCHDB-2623
URL: https://issues.apache.org/jira/browse/COUCHDB-2623
Project: CouchDB
Issue Type: Task
Security Level: public (Regular issues)
Reporter: Alexander Shorin
We need to double check our configs to ensure that there are no outdated
options there and all the present ones are actual to their defaults. For
instance:
{code}
[stats]
; rate is in milliseconds
rate = 1000
; sample intervals are in seconds
samples = [0, 60, 300, 900]
{code}
Is not actual anymore since we'd change the stats app, but those might expose
new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (COUCHDB-2620) Rename cassim db to _metadata
[ https://issues.apache.org/jira/browse/COUCHDB-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin reassigned COUCHDB-2620: - Assignee: Alexander Shorin > Rename cassim db to _metadata > - > > Key: COUCHDB-2620 > URL: https://issues.apache.org/jira/browse/COUCHDB-2620 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: Alexander Shorin >Assignee: Alexander Shorin > > After IRC conversation with [~janl] and [~chewbranca] we -decided- are > proposing to rename cassim database into something more specific and > concrete. This database currently holds only _security of all cluster > databases, but is designed for more. In future, we could use it to handle > config-per-database feature and etc. The _metadata name reflects nicely such > propose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2620) Rename cassim db to _metadata
[ https://issues.apache.org/jira/browse/COUCHDB-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333814#comment-14333814 ] Alexander Shorin commented on COUCHDB-2620: --- Yes, "decided" might be a too strong word. Fixed that. > Rename cassim db to _metadata > - > > Key: COUCHDB-2620 > URL: https://issues.apache.org/jira/browse/COUCHDB-2620 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: Alexander Shorin > > After IRC conversation with [~janl] and [~chewbranca] we -decided- are > proposing to rename cassim database into something more specific and > concrete. This database currently holds only _security of all cluster > databases, but is designed for more. In future, we could use it to handle > config-per-database feature and etc. The _metadata name reflects nicely such > propose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2620) Rename cassim db to _metadata
[ https://issues.apache.org/jira/browse/COUCHDB-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2620: -- Description: After IRC conversation with [~janl] and [~chewbranca] we -decided- are proposing to rename cassim database into something more specific and concrete. This database currently holds only _security of all cluster databases, but is designed for more. In future, we could use it to handle config-per-database feature and etc. The _metadata name reflects nicely such propose. (was: After IRC conversation with [~janl] and [~chewbranca] we decided to rename cassim database into something more specific and concrete. This database currently holds only _security of all cluster databases, but is designed for more. In future, we could use it to handle config-per-database feature and etc. The _metadata name reflects nicely such propose.) > Rename cassim db to _metadata > - > > Key: COUCHDB-2620 > URL: https://issues.apache.org/jira/browse/COUCHDB-2620 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: Alexander Shorin > > After IRC conversation with [~janl] and [~chewbranca] we -decided- are > proposing to rename cassim database into something more specific and > concrete. This database currently holds only _security of all cluster > databases, but is designed for more. In future, we could use it to handle > config-per-database feature and etc. The _metadata name reflects nicely such > propose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2621) Hide _metadata database from the world by default
[ https://issues.apache.org/jira/browse/COUCHDB-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2621: -- Description: After IRC conversation with [~janl] and [~chewbranca] we -decided- are proposing to hide _metadata database from the world by blocking all the access to it via HTTP API. The motivation is the following: - it lacks of validation logic, but adding such may hurt overall performance a more; - it creates a confusion about database security management: should users use /db/_security endpoint of /_metadata/db@security one? - technically, it allows to replicate databases metadata across the cluster, but this use case is a dark room of black cats; - there is something about quorum thing, but I didn't get that completely (: The proposal is to add chttpd handler which returns a HTTP error (403 Forbidden?) on /_metadata request and only allows to access to it from HTTP after setting couchdb/expose_metadata_database with value true in config file. was: After IRC conversation with [~janl] and [~chewbranca] we decided to hide _metadata database from the world by blocking all the access to it via HTTP API. The motivation is the following: - it lacks of validation logic, but adding such may hurt overall performance a more; - it creates a confusion about database security management: should users use /db/_security endpoint of /_metadata/db@security one? - technically, it allows to replicate databases metadata across the cluster, but this use case is a dark room of black cats; - there is something about quorum thing, but I didn't get that completely (: The proposal is to add chttpd handler which returns a HTTP error (403 Forbidden?) on /_metadata request and only allows to access to it from HTTP after setting couchdb/expose_metadata_database with value true in config file. > Hide _metadata database from the world by default > - > > Key: COUCHDB-2621 > URL: https://issues.apache.org/jira/browse/COUCHDB-2621 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: Alexander Shorin > > After IRC conversation with [~janl] and [~chewbranca] we -decided- are > proposing to hide _metadata database from the world by blocking all the > access to it via HTTP API. The motivation is the following: > - it lacks of validation logic, but adding such may hurt overall performance > a more; > - it creates a confusion about database security management: should users use > /db/_security endpoint of /_metadata/db@security one? > - technically, it allows to replicate databases metadata across the cluster, > but this use case is a dark room of black cats; > - there is something about quorum thing, but I didn't get that completely (: > The proposal is to add chttpd handler which returns a HTTP error (403 > Forbidden?) on /_metadata request and only allows to access to it from HTTP > after setting couchdb/expose_metadata_database with value true in config file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2621) Hide _metadata database from the world by default
Alexander Shorin created COUCHDB-2621: - Summary: Hide _metadata database from the world by default Key: COUCHDB-2621 URL: https://issues.apache.org/jira/browse/COUCHDB-2621 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Database Core Reporter: Alexander Shorin After IRC conversation with [~janl] and [~chewbranca] we decided to hide _metadata database from the world by blocking all the access to it via HTTP API. The motivation is the following: - it lacks of validation logic, but adding such may hurt overall performance a more; - it creates a confusion about database security management: should users use /db/_security endpoint of /_metadata/db@security one? - technically, it allows to replicate databases metadata across the cluster, but this use case is a dark room of black cats; - there is something about quorum thing, but I didn't get that completely (: The proposal is to add chttpd handler which returns a HTTP error (403 Forbidden?) on /_metadata request and only allows to access to it from HTTP after setting couchdb/expose_metadata_database with value true in config file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2620) Rename cassim db to _metadata
Alexander Shorin created COUCHDB-2620: - Summary: Rename cassim db to _metadata Key: COUCHDB-2620 URL: https://issues.apache.org/jira/browse/COUCHDB-2620 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Database Core Reporter: Alexander Shorin After IRC conversation with [~janl] and [~chewbranca] we decided to rename cassim database into something more specific and concrete. This database currently holds only _security of all cluster databases, but is designed for more. In future, we could use it to handle config-per-database feature and etc. The _metadata name reflects nicely such propose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (COUCHDB-2619) Make all system databases start with underscore
[ https://issues.apache.org/jira/browse/COUCHDB-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin reassigned COUCHDB-2619: - Assignee: Alexander Shorin > Make all system databases start with underscore > --- > > Key: COUCHDB-2619 > URL: https://issues.apache.org/jira/browse/COUCHDB-2619 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Database Core >Reporter: Alexander Shorin >Assignee: Alexander Shorin > > With 2.0 here comes three new system databases: dbs, nodes and cassim. They > need to have underscore in prefix as like as _users and _replicator has to > explicitly denote them from user databases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2619) Make all system databases start with underscore
Alexander Shorin created COUCHDB-2619: - Summary: Make all system databases start with underscore Key: COUCHDB-2619 URL: https://issues.apache.org/jira/browse/COUCHDB-2619 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Database Core Reporter: Alexander Shorin With 2.0 here comes three new system databases: dbs, nodes and cassim. They need to have underscore in prefix as like as _users and _replicator has to explicitly denote them from user databases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2617) Align database list rows text
[ https://issues.apache.org/jira/browse/COUCHDB-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2617: -- Attachment: couchdb-2617-ff.png > Align database list rows text > - > > Key: COUCHDB-2617 > URL: https://issues.apache.org/jira/browse/COUCHDB-2617 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Priority: Trivial > Attachments: couchdb-2617-ff.png > > > They should be in the middle. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2617) Align database list rows text
[ https://issues.apache.org/jira/browse/COUCHDB-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2617: -- Priority: Trivial (was: Major) > Align database list rows text > - > > Key: COUCHDB-2617 > URL: https://issues.apache.org/jira/browse/COUCHDB-2617 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Priority: Trivial > > They should be in the middle. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2617) Align database list rows text
Alexander Shorin created COUCHDB-2617: - Summary: Align database list rows text Key: COUCHDB-2617 URL: https://issues.apache.org/jira/browse/COUCHDB-2617 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin They should be in the middle. See attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2616) Align navbar text and icons
[ https://issues.apache.org/jira/browse/COUCHDB-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2616: -- Priority: Trivial (was: Major) > Align navbar text and icons > --- > > Key: COUCHDB-2616 > URL: https://issues.apache.org/jira/browse/COUCHDB-2616 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin >Priority: Trivial > Attachments: couchdb-2616-ff.png > > > They are currently dances, see attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2616) Align navbar text and icons
[ https://issues.apache.org/jira/browse/COUCHDB-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2616: -- Attachment: couchdb-2616-ff.png Follow the baselines. > Align navbar text and icons > --- > > Key: COUCHDB-2616 > URL: https://issues.apache.org/jira/browse/COUCHDB-2616 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: Fauxton >Reporter: Alexander Shorin > Attachments: couchdb-2616-ff.png > > > They are currently dances, see attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2616) Align navbar text and icons
Alexander Shorin created COUCHDB-2616: - Summary: Align navbar text and icons Key: COUCHDB-2616 URL: https://issues.apache.org/jira/browse/COUCHDB-2616 Project: CouchDB Issue Type: Bug Security Level: public (Regular issues) Components: Fauxton Reporter: Alexander Shorin They are currently dances, see attached screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2615) Ensure that rebar exists and his version is correct
[ https://issues.apache.org/jira/browse/COUCHDB-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2615: -- Fix Version/s: 2.0.0 > Ensure that rebar exists and his version is correct > --- > > Key: COUCHDB-2615 > URL: https://issues.apache.org/jira/browse/COUCHDB-2615 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Build System >Reporter: Alexander Shorin > Fix For: 2.0.0 > > > Currently, we relay on the fact that rebar is installed somehow in the system > before user runs ./configure. This causes the following issues: > - rebar may actually not being available > - rebar version may be too old > To avoid these issues and make install process more "relaxed", on ./configure > phare we could build rebar before fetch any dependencies. Hopefully, we have > [own fork|https://git-wip-us.apache.org/repos/asf?p=couchdb-rebar.git] to not > depend on remote upstream. > However, it's not wise to always build our own rebar on ./configure - on the > end user system there could be already installed rebar with the right > version. For this case, we need to provide a switch flag like > --with-system-rebar for ./configure script which check if the system rebar > version is correct (iirc, we need 2.3.1+, but need to double check that). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COUCHDB-2615) Ensure that rebar exists and his version is correct
[ https://issues.apache.org/jira/browse/COUCHDB-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-2615: -- Priority: Blocker (was: Major) > Ensure that rebar exists and his version is correct > --- > > Key: COUCHDB-2615 > URL: https://issues.apache.org/jira/browse/COUCHDB-2615 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Build System >Reporter: Alexander Shorin >Priority: Blocker > Fix For: 2.0.0 > > > Currently, we relay on the fact that rebar is installed somehow in the system > before user runs ./configure. This causes the following issues: > - rebar may actually not being available > - rebar version may be too old > To avoid these issues and make install process more "relaxed", on ./configure > phare we could build rebar before fetch any dependencies. Hopefully, we have > [own fork|https://git-wip-us.apache.org/repos/asf?p=couchdb-rebar.git] to not > depend on remote upstream. > However, it's not wise to always build our own rebar on ./configure - on the > end user system there could be already installed rebar with the right > version. For this case, we need to provide a switch flag like > --with-system-rebar for ./configure script which check if the system rebar > version is correct (iirc, we need 2.3.1+, but need to double check that). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COUCHDB-2615) Ensure that rebar exists and his version is correct
Alexander Shorin created COUCHDB-2615: - Summary: Ensure that rebar exists and his version is correct Key: COUCHDB-2615 URL: https://issues.apache.org/jira/browse/COUCHDB-2615 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Build System Reporter: Alexander Shorin Currently, we relay on the fact that rebar is installed somehow in the system before user runs ./configure. This causes the following issues: - rebar may actually not being available - rebar version may be too old To avoid these issues and make install process more "relaxed", on ./configure phare we could build rebar before fetch any dependencies. Hopefully, we have [own fork|https://git-wip-us.apache.org/repos/asf?p=couchdb-rebar.git] to not depend on remote upstream. However, it's not wise to always build our own rebar on ./configure - on the end user system there could be already installed rebar with the right version. For this case, we need to provide a switch flag like --with-system-rebar for ./configure script which check if the system rebar version is correct (iirc, we need 2.3.1+, but need to double check that). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COUCHDB-2614) Selectors with {$eq: 'foo', $gte: 'foo'} cause 500 error
[
https://issues.apache.org/jira/browse/COUCHDB-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14332468#comment-14332468
]
Alexander Shorin commented on COUCHDB-2614:
---
function_clause happens because start_key/1 receives [empty] argument. What it
suppose to do with that?
> Selectors with {$eq: 'foo', $gte: 'foo'} cause 500 error
>
>
> Key: COUCHDB-2614
> URL: https://issues.apache.org/jira/browse/COUCHDB-2614
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Nolan Lawson
>
> Steps to repro in curl:
> {code}
> MYDB=http://whatever.cloudant.com/somedb
> curl "$MYDB/_bulk_docs" -H 'Content-Type: application/json' --data-binary
> '{"new_edits":true,"docs":[{"name":"mario","_id":"mario","rank":5,"series":"mario","debut":1981},{"name":"jigglypuff","_id":"puff","rank":8,"series":"pokemon","debut":1996},{"name":"link","rank":10,"_id":"link","series":"zelda","debut":1986},{"name":"donkey
>
> kong","rank":7,"_id":"dk","series":"mario","debut":1981},{"name":"pikachu","series":"pokemon","_id":"pikachu","rank":1,"debut":1996},{"name":"captain
>
> falcon","_id":"falcon","rank":4,"series":"f-zero","debut":1990},{"name":"luigi","rank":11,"_id":"luigi","series":"mario","debut":1983},{"name":"fox","_id":"fox","rank":3,"series":"star
>
> fox","debut":1993},{"name":"ness","rank":9,"_id":"ness","series":"earthbound","debut":1994},{"name":"samus","rank":12,"_id":"samus","series":"metroid","debut":1986},{"name":"yoshi","_id":"yoshi","rank":6,"series":"mario","debut":1990},{"name":"kirby","_id":"kirby","series":"kirby","rank":2,"debut":1992}]}'
> curl "$MYDB/_index" -H 'Content-Type: application/json' --data-binary
> '{"index":{"fields":["series"]}}'
> curl "$MYDB/_find" -H 'Content-Type: application/json' --data-binary
> '{"selector":{"$and":[{"series":{"$gte":"mario"}},{"series":{"$eq":"f-zero"}},{"series":{"$eq":"mario"}}]},"fields":["_id"]}'
> {code}
> The error I get back is:
> {code:javascript}
> {"error":"function_clause","reason":null,"ref":2609331215}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COUCHDB-2614) Selectors with {$eq: 'foo', $gte: 'foo'} cause 500 error
[
https://issues.apache.org/jira/browse/COUCHDB-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14332461#comment-14332461
]
Alexander Shorin commented on COUCHDB-2614:
---
On CouchDB 2.0 (current master for this comment timestamp) it causes the
following error in logs:
{code}
2015-02-23 03:50:40.454 [error] node1@127.0.0.1 <0.370.0> req_err(4156138022)
unknown_error : function_clause
[<<"mango_idx_view:start_key/1 L118">>,<<"mango_cursor_view:execute/3
L71">>,<<"mango_httpd:handle_find_req/2 L137">>,<<"mango_httpd:handle_req/2
L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
2015-02-23 03:50:40.454 [error] node1@127.0.0.1 <0.370.0> httpd 500 error
response:
{"error":"unknown_error","reason":"function_clause","ref":4156138022}
2015-02-23 03:50:40.455 [notice] node1@127.0.0.1 <0.370.0> ffc69f31 127.0.0.1
localhost:16984 POST /test/_find 500 ok 45
{code}
> Selectors with {$eq: 'foo', $gte: 'foo'} cause 500 error
>
>
> Key: COUCHDB-2614
> URL: https://issues.apache.org/jira/browse/COUCHDB-2614
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Nolan Lawson
>
> Steps to repro in curl:
> {code}
> MYDB=http://whatever.cloudant.com/somedb
> curl "$MYDB/_bulk_docs" -H 'Content-Type: application/json' --data-binary
> '{"new_edits":true,"docs":[{"name":"mario","_id":"mario","rank":5,"series":"mario","debut":1981},{"name":"jigglypuff","_id":"puff","rank":8,"series":"pokemon","debut":1996},{"name":"link","rank":10,"_id":"link","series":"zelda","debut":1986},{"name":"donkey
>
> kong","rank":7,"_id":"dk","series":"mario","debut":1981},{"name":"pikachu","series":"pokemon","_id":"pikachu","rank":1,"debut":1996},{"name":"captain
>
> falcon","_id":"falcon","rank":4,"series":"f-zero","debut":1990},{"name":"luigi","rank":11,"_id":"luigi","series":"mario","debut":1983},{"name":"fox","_id":"fox","rank":3,"series":"star
>
> fox","debut":1993},{"name":"ness","rank":9,"_id":"ness","series":"earthbound","debut":1994},{"name":"samus","rank":12,"_id":"samus","series":"metroid","debut":1986},{"name":"yoshi","_id":"yoshi","rank":6,"series":"mario","debut":1990},{"name":"kirby","_id":"kirby","series":"kirby","rank":2,"debut":1992}]}'
> curl "$MYDB/_index" -H 'Content-Type: application/json' --data-binary
> '{"index":{"fields":["series"]}}'
> curl "$MYDB/_find" -H 'Content-Type: application/json' --data-binary
> '{"selector":{"$and":[{"series":{"$gte":"mario"}},{"series":{"$eq":"f-zero"}},{"series":{"$eq":"mario"}}]},"fields":["_id"]}'
> {code}
> The error I get back is:
> {code:javascript}
> {"error":"function_clause","reason":null,"ref":2609331215}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COUCHDB-2613) function_clause on mango find
[
https://issues.apache.org/jira/browse/COUCHDB-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-2613.
-
Resolution: Invalid
> function_clause on mango find
> -
>
> Key: COUCHDB-2613
> URL: https://issues.apache.org/jira/browse/COUCHDB-2613
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> curl -XPOST 'http://localhost:16984/test/_find' -d '{"selector":{"fields":
> ["_id", "_rev"]}}'
> {"error":"unknown_error","reason":"function_clause","ref":3835390434}
> {code}
> {code}
> 2015-02-22 00:08:58.166 [error] node1@127.0.0.1 <0.372.0> req_err(3835390434)
> unknown_error : function_clause
> [<<"ddoc_cache:open/2 L82">>,<<"mango_idx:list/1
> L54">>,<<"mango_cursor:create/3 L34">>,<<"mango_crud:find/5
> L52">>,<<"mango_httpd:handle_find_req/2 L137">>,<<"mango_httpd:handle_req/2
> L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5 L93">>]
> 2015-02-22 00:08:58.167 [error] node1@127.0.0.1 <0.372.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":3835390434}
> 2015-02-22 00:08:58.167 [notice] node1@127.0.0.1 <0.372.0> 23de2df3 127.0.0.1
> localhost:16984 POST /test/_find 500 ok 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COUCHDB-2609) function_clause on explain mango index
[
https://issues.apache.org/jira/browse/COUCHDB-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-2609.
-
Resolution: Invalid
> function_clause on explain mango index
> --
>
> Key: COUCHDB-2609
> URL: https://issues.apache.org/jira/browse/COUCHDB-2609
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> $ curl -XPOST 'http://localhost:16984/test/_explain' -d '{"selector": {"foo":
> {"$gt": "bar"}}}'
> {"error":"unknown_error","reason":"function_clause","ref":616973802}
> {code}
> Logs:
> {code}
> 2015-02-21 18:06:53.041 [error] node1@127.0.0.1 <0.5028.0> req_err(616973802)
> unknown_error : function_clause
> [<<"ddoc_cache:open/2 L82">>,<<"mango_idx:list/1
> L54">>,<<"mango_cursor:create/3 L34">>,<<"mango_crud:explain/3
> L105">>,<<"mango_httpd:handle_explain_req/2
> L126">>,<<"mango_httpd:handle_req/2 L28">>,<<"chttpd:handle_request/1
> L210">>,<<"mochiweb_http:headers/5 L93">>]
> 2015-02-21 18:06:53.041 [error] node1@127.0.0.1 <0.5028.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":616973802}
> 2015-02-21 18:06:53.042 [notice] node1@127.0.0.1 <0.5028.0> cd1e539d
> 127.0.0.1 localhost:16984 POST /test/_explain 500 ok 4
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (COUCHDB-2608) function_clause on update mango index
[
https://issues.apache.org/jira/browse/COUCHDB-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-2608.
-
Resolution: Invalid
> function_clause on update mango index
> -
>
> Key: COUCHDB-2608
> URL: https://issues.apache.org/jira/browse/COUCHDB-2608
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> $ curl -XPOST http://localhost:16984/test/_index -d '{"index":{"fields":
> ["foo"]}, "ddoc": "foobarbaz", "type": "json"}'
> $ curl -XPOST http://localhost:16984/test/_index -d '{"index":{"fields":
> ["bar"]}, "ddoc": "foobarbaz", "type": "json"}'
> {"error":"unknown_error","reason":"function_clause","ref":283694227}
> {code}
> Logs:
> {code}
> 2015-02-21 18:03:26.089 [notice] node1@127.0.0.1 <0.3121.0> f80ae1e2
> 127.0.0.1 localhost:16984 POST /test/_index 500 ok 3
> 2015-02-21 18:03:31.472 [error] node1@127.0.0.1 <0.4653.0> req_err(283694227)
> unknown_error : function_clause
> [<<"mango_util:check_lang/1 L157">>,<<"mango_util:load_ddoc/2
> L72">>,<<"mango_httpd:handle_index_req/2 L60">>,<<"mango_httpd:handle_req/2
> L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> 2015-02-21 18:03:31.472 [error] node1@127.0.0.1 <0.4653.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":283694227}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2613) function_clause on mango find
[
https://issues.apache.org/jira/browse/COUCHDB-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2613:
--
Priority: Blocker (was: Major)
> function_clause on mango find
> -
>
> Key: COUCHDB-2613
> URL: https://issues.apache.org/jira/browse/COUCHDB-2613
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> curl -XPOST 'http://localhost:16984/test/_find' -d '{"selector":{"fields":
> ["_id", "_rev"]}}'
> {"error":"unknown_error","reason":"function_clause","ref":3835390434}
> {code}
> {code}
> 2015-02-22 00:08:58.166 [error] node1@127.0.0.1 <0.372.0> req_err(3835390434)
> unknown_error : function_clause
> [<<"ddoc_cache:open/2 L82">>,<<"mango_idx:list/1
> L54">>,<<"mango_cursor:create/3 L34">>,<<"mango_crud:find/5
> L52">>,<<"mango_httpd:handle_find_req/2 L137">>,<<"mango_httpd:handle_req/2
> L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5 L93">>]
> 2015-02-22 00:08:58.167 [error] node1@127.0.0.1 <0.372.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":3835390434}
> 2015-02-22 00:08:58.167 [notice] node1@127.0.0.1 <0.372.0> 23de2df3 127.0.0.1
> localhost:16984 POST /test/_find 500 ok 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2613) function_clause on mango find
[
https://issues.apache.org/jira/browse/COUCHDB-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2613:
--
Fix Version/s: 2.0.0
> function_clause on mango find
> -
>
> Key: COUCHDB-2613
> URL: https://issues.apache.org/jira/browse/COUCHDB-2613
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> curl -XPOST 'http://localhost:16984/test/_find' -d '{"selector":{"fields":
> ["_id", "_rev"]}}'
> {"error":"unknown_error","reason":"function_clause","ref":3835390434}
> {code}
> {code}
> 2015-02-22 00:08:58.166 [error] node1@127.0.0.1 <0.372.0> req_err(3835390434)
> unknown_error : function_clause
> [<<"ddoc_cache:open/2 L82">>,<<"mango_idx:list/1
> L54">>,<<"mango_cursor:create/3 L34">>,<<"mango_crud:find/5
> L52">>,<<"mango_httpd:handle_find_req/2 L137">>,<<"mango_httpd:handle_req/2
> L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5 L93">>]
> 2015-02-22 00:08:58.167 [error] node1@127.0.0.1 <0.372.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":3835390434}
> 2015-02-22 00:08:58.167 [notice] node1@127.0.0.1 <0.372.0> 23de2df3 127.0.0.1
> localhost:16984 POST /test/_find 500 ok 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2613) function_clause on mango find
Alexander Shorin created COUCHDB-2613:
-
Summary: function_clause on mango find
Key: COUCHDB-2613
URL: https://issues.apache.org/jira/browse/COUCHDB-2613
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Mango
Reporter: Alexander Shorin
{code}
curl -XPOST 'http://localhost:16984/test/_find' -d '{"selector":{"fields":
["_id", "_rev"]}}'
{"error":"unknown_error","reason":"function_clause","ref":3835390434}
{code}
{code}
2015-02-22 00:08:58.166 [error] node1@127.0.0.1 <0.372.0> req_err(3835390434)
unknown_error : function_clause
[<<"ddoc_cache:open/2 L82">>,<<"mango_idx:list/1
L54">>,<<"mango_cursor:create/3 L34">>,<<"mango_crud:find/5
L52">>,<<"mango_httpd:handle_find_req/2 L137">>,<<"mango_httpd:handle_req/2
L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5 L93">>]
2015-02-22 00:08:58.167 [error] node1@127.0.0.1 <0.372.0> httpd 500 error
response:
{"error":"unknown_error","reason":"function_clause","ref":3835390434}
2015-02-22 00:08:58.167 [notice] node1@127.0.0.1 <0.372.0> 23de2df3 127.0.0.1
localhost:16984 POST /test/_find 500 ok 2
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2609) function_clause on explain mango index
[
https://issues.apache.org/jira/browse/COUCHDB-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2609:
--
Fix Version/s: 2.0.0
> function_clause on explain mango index
> --
>
> Key: COUCHDB-2609
> URL: https://issues.apache.org/jira/browse/COUCHDB-2609
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> $ curl -XPOST 'http://localhost:16984/test/_explain' -d '{"selector": {"foo":
> {"$gt": "bar"}}}'
> {"error":"unknown_error","reason":"function_clause","ref":616973802}
> {code}
> Logs:
> {code}
> 2015-02-21 18:06:53.041 [error] node1@127.0.0.1 <0.5028.0> req_err(616973802)
> unknown_error : function_clause
> [<<"ddoc_cache:open/2 L82">>,<<"mango_idx:list/1
> L54">>,<<"mango_cursor:create/3 L34">>,<<"mango_crud:explain/3
> L105">>,<<"mango_httpd:handle_explain_req/2
> L126">>,<<"mango_httpd:handle_req/2 L28">>,<<"chttpd:handle_request/1
> L210">>,<<"mochiweb_http:headers/5 L93">>]
> 2015-02-21 18:06:53.041 [error] node1@127.0.0.1 <0.5028.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":616973802}
> 2015-02-21 18:06:53.042 [notice] node1@127.0.0.1 <0.5028.0> cd1e539d
> 127.0.0.1 localhost:16984 POST /test/_explain 500 ok 4
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2609) function_clause on explain mango index
[
https://issues.apache.org/jira/browse/COUCHDB-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2609:
--
Priority: Blocker (was: Major)
> function_clause on explain mango index
> --
>
> Key: COUCHDB-2609
> URL: https://issues.apache.org/jira/browse/COUCHDB-2609
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> $ curl -XPOST 'http://localhost:16984/test/_explain' -d '{"selector": {"foo":
> {"$gt": "bar"}}}'
> {"error":"unknown_error","reason":"function_clause","ref":616973802}
> {code}
> Logs:
> {code}
> 2015-02-21 18:06:53.041 [error] node1@127.0.0.1 <0.5028.0> req_err(616973802)
> unknown_error : function_clause
> [<<"ddoc_cache:open/2 L82">>,<<"mango_idx:list/1
> L54">>,<<"mango_cursor:create/3 L34">>,<<"mango_crud:explain/3
> L105">>,<<"mango_httpd:handle_explain_req/2
> L126">>,<<"mango_httpd:handle_req/2 L28">>,<<"chttpd:handle_request/1
> L210">>,<<"mochiweb_http:headers/5 L93">>]
> 2015-02-21 18:06:53.041 [error] node1@127.0.0.1 <0.5028.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":616973802}
> 2015-02-21 18:06:53.042 [notice] node1@127.0.0.1 <0.5028.0> cd1e539d
> 127.0.0.1 localhost:16984 POST /test/_explain 500 ok 4
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2608) function_clause on update mango index
[
https://issues.apache.org/jira/browse/COUCHDB-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2608:
--
Priority: Blocker (was: Major)
> function_clause on update mango index
> -
>
> Key: COUCHDB-2608
> URL: https://issues.apache.org/jira/browse/COUCHDB-2608
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
>
> {code}
> $ curl -XPOST http://localhost:16984/test/_index -d '{"index":{"fields":
> ["foo"]}, "ddoc": "foobarbaz", "type": "json"}'
> $ curl -XPOST http://localhost:16984/test/_index -d '{"index":{"fields":
> ["bar"]}, "ddoc": "foobarbaz", "type": "json"}'
> {"error":"unknown_error","reason":"function_clause","ref":283694227}
> {code}
> Logs:
> {code}
> 2015-02-21 18:03:26.089 [notice] node1@127.0.0.1 <0.3121.0> f80ae1e2
> 127.0.0.1 localhost:16984 POST /test/_index 500 ok 3
> 2015-02-21 18:03:31.472 [error] node1@127.0.0.1 <0.4653.0> req_err(283694227)
> unknown_error : function_clause
> [<<"mango_util:check_lang/1 L157">>,<<"mango_util:load_ddoc/2
> L72">>,<<"mango_httpd:handle_index_req/2 L60">>,<<"mango_httpd:handle_req/2
> L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> 2015-02-21 18:03:31.472 [error] node1@127.0.0.1 <0.4653.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":283694227}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COUCHDB-2608) function_clause on update mango index
[
https://issues.apache.org/jira/browse/COUCHDB-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-2608:
--
Fix Version/s: 2.0.0
> function_clause on update mango index
> -
>
> Key: COUCHDB-2608
> URL: https://issues.apache.org/jira/browse/COUCHDB-2608
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Mango
>Reporter: Alexander Shorin
>Priority: Blocker
> Fix For: 2.0.0
>
>
> {code}
> $ curl -XPOST http://localhost:16984/test/_index -d '{"index":{"fields":
> ["foo"]}, "ddoc": "foobarbaz", "type": "json"}'
> $ curl -XPOST http://localhost:16984/test/_index -d '{"index":{"fields":
> ["bar"]}, "ddoc": "foobarbaz", "type": "json"}'
> {"error":"unknown_error","reason":"function_clause","ref":283694227}
> {code}
> Logs:
> {code}
> 2015-02-21 18:03:26.089 [notice] node1@127.0.0.1 <0.3121.0> f80ae1e2
> 127.0.0.1 localhost:16984 POST /test/_index 500 ok 3
> 2015-02-21 18:03:31.472 [error] node1@127.0.0.1 <0.4653.0> req_err(283694227)
> unknown_error : function_clause
> [<<"mango_util:check_lang/1 L157">>,<<"mango_util:load_ddoc/2
> L72">>,<<"mango_httpd:handle_index_req/2 L60">>,<<"mango_httpd:handle_req/2
> L28">>,<<"chttpd:handle_request/1 L210">>,<<"mochiweb_http:headers/5
> L93">>,<<"proc_lib:init_p_do_apply/3 L237">>]
> 2015-02-21 18:03:31.472 [error] node1@127.0.0.1 <0.4653.0> httpd 500 error
> response:
> {"error":"unknown_error","reason":"function_clause","ref":283694227}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COUCHDB-2612) Port mango tests from python to erlang
Alexander Shorin created COUCHDB-2612: - Summary: Port mango tests from python to erlang Key: COUCHDB-2612 URL: https://issues.apache.org/jira/browse/COUCHDB-2612 Project: CouchDB Issue Type: Improvement Security Level: public (Regular issues) Components: Mango, Test Suite Reporter: Alexander Shorin Currently they are done in Python which means they are out of our make check run and we cannot be sure that our releases will ship with working mango. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
