You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jens Alfke <je...@couchbase.com> on 2011/07/13 03:38:59 UTC
Unexpected response for ?open_revs=all
I’m trying to get a list of conflicting revisions by using the “?open_revs=all” query parameter, as described in the conflict documentation in the wiki[1]. But when I test this with curl, the output is completely unexpected — instead of a JSON array as documented, I get a MIME multipart body. What’s going on?
In this example the document isn’t actually in conflict, as I haven’t synthesized a conflict in my test database yet (though I will soon thanks to Paul’s handy Python script!)
$ curl -i 'http://127.0.0.1:5984/db/3aaa5e74e5d96db3b2248fb1c404eb65?open_revs=all’
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.2.0a-eb77a97-git (Erlang OTP/R14B01)
Date: Wed, 13 Jul 2011 01:16:36 GMT
Content-Type: multipart/mixed; boundary="5316aac5e82bfd1b98ba15d212819f24"
--5316aac5e82bfd1b98ba15d212819f24
Content-Type: application/json
{"_id":"3aaa5e74e5d96db3b2248fb1c404eb65","_rev":"7-7e833e1c2ee3db8e4ae3f615c20ca592","first":"Jens","last":"Alfke","email":"jens@mooseyard.com"}
--5316aac5e82bfd1b98ba15d212819f24—
—Jens
[1] http://wiki.apache.org/couchdb/Replication_and_conflicts
Re: Unexpected response for ?open_revs=all
Posted by Mike Leddy <mi...@loop.com.br>.
Hi Jens,
You can get the behaviour you want if you can set the Accept header in the
http request ie:
$ curl -i -H 'Accept: application/json' 'http://127.0.0.1:5984/test/one?open_revs=all'
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.2.0a-0e1af07-git (Erlang OTP/R14B03)
Date: Wed, 13 Jul 2011 12:00:23 GMT
Content-Type: application/json
Cache-Control: must-revalidate
[{"ok":{"_id":"one","_rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}}]
As opposed to:
$ curl -i 'http://127.0.0.1:5984/test/one?open_revs=all'
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: CouchDB/1.2.0a-0e1af07-git (Erlang OTP/R14B03)
Date: Wed, 13 Jul 2011 12:02:19 GMT
Content-Type: multipart/mixed; boundary="2d29ffaa2362c73c3c22a9d434aa8859"
--2d29ffaa2362c73c3c22a9d434aa8859
Content-Type: application/json
{"_id":"one","_rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}
--2d29ffaa2362c73c3c22a9d434aa8859--
Regards,
Mike
On Tue, 2011-07-12 at 18:38 -0700, Jens Alfke wrote:
> I’m trying to get a list of conflicting revisions by using the “?open_revs=all” query parameter, as described in the conflict documentation in the wiki[1]. But when I test this with curl, the output is completely unexpected — instead of a JSON array as documented, I get a MIME multipart body. What’s going on?
>
> In this example the document isn’t actually in conflict, as I haven’t synthesized a conflict in my test database yet (though I will soon thanks to Paul’s handy Python script!)
>
> $ curl -i 'http://127.0.0.1:5984/db/3aaa5e74e5d96db3b2248fb1c404eb65?open_revs=all’
> HTTP/1.1 200 OK
> Transfer-Encoding: chunked
> Server: CouchDB/1.2.0a-eb77a97-git (Erlang OTP/R14B01)
> Date: Wed, 13 Jul 2011 01:16:36 GMT
> Content-Type: multipart/mixed; boundary="5316aac5e82bfd1b98ba15d212819f24"
>
> --5316aac5e82bfd1b98ba15d212819f24
> Content-Type: application/json
>
> {"_id":"3aaa5e74e5d96db3b2248fb1c404eb65","_rev":"7-7e833e1c2ee3db8e4ae3f615c20ca592","first":"Jens","last":"Alfke","email":"jens@mooseyard.com"}
> --5316aac5e82bfd1b98ba15d212819f24—
>
> —Jens
>
> [1] http://wiki.apache.org/couchdb/Replication_and_conflicts
Re: Unexpected response for ?open_revs=all
Posted by Robert Newson <rn...@apache.org>.
I'm not saying the wiki is useless, not by a long way, but it isn't
completely accurate. While I agree that that's unachievable, anyway
can, and does, edit the wiki based on their understanding of the code,
and that isn't always good. Worse, accurate statements can be made
less so over time.
All I'm advocating is that the committers on the project, including
myself, further commit ourselves to produce as complete and accurate a
description of the CouchDB API as we can, same as we try to produce
bug free code and good tests. Contributions from the outside are
welcome and encouraged, same as they are for bug fixes.
So, I'm not slamming the wiki, I'm slapping the committers (again,
myself included) for not yet including docs as part of our release
cycle already. :)
B.
On 13 July 2011 18:32, Jens Alfke <je...@couchbase.com> wrote:
>
> On Jul 13, 2011, at 10:07 AM, Robert Newson wrote:
>
>> It's clear that the wiki serves poorly as an official source of
>> documentation. This is not surprising given that's not where their
>> strengths lie.
>
> Agreed in principle, but the API references pages on the wiki have been extremely useful to me in both learning & coding. I find it a lot easier to learn from references like these than from tutorials in books. I’m happy to give back (when appropriate) by fixing up the wiki docs until they're superseded.
>
>> There's an effort to create solid documentation that will form part of
>> future releases. They will live under source control with the code
>> base where we can make it part of our routine to ensure their accuracy
>> over time.
>
> Sounds good! How can I get involved, at least to the extent of reading what exists and reporting issues?
>
>
> Oh, and back to the topic at hand:
>
>> The ?conflicts=true parameter should be used here instead.
>
> I’m partial to ?open_revs because it returns the contents of all conflicting revisions in one call, instead of requiring one or more extra GETs. Is there a way to make ?conflicts do that too?
>
> —Jens
>
>
Re: Unexpected response for ?open_revs=all
Posted by Jens Alfke <je...@couchbase.com>.
On Jul 13, 2011, at 10:07 AM, Robert Newson wrote:
> It's clear that the wiki serves poorly as an official source of
> documentation. This is not surprising given that's not where their
> strengths lie.
Agreed in principle, but the API references pages on the wiki have been extremely useful to me in both learning & coding. I find it a lot easier to learn from references like these than from tutorials in books. I’m happy to give back (when appropriate) by fixing up the wiki docs until they're superseded.
> There's an effort to create solid documentation that will form part of
> future releases. They will live under source control with the code
> base where we can make it part of our routine to ensure their accuracy
> over time.
Sounds good! How can I get involved, at least to the extent of reading what exists and reporting issues?
Oh, and back to the topic at hand:
> The ?conflicts=true parameter should be used here instead.
I’m partial to ?open_revs because it returns the contents of all conflicting revisions in one call, instead of requiring one or more extra GETs. Is there a way to make ?conflicts do that too?
—Jens
Re: Unexpected response for ?open_revs=all
Posted by Robert Newson <rn...@apache.org>.
It was said, or at least implied, in another thread.
Please don't remove it from the wiki.
It's clear that the wiki serves poorly as an official source of
documentation. This is not surprising given that's not where their
strengths lie.
There's an effort to create solid documentation that will form part of
future releases. They will live under source control with the code
base where we can make it part of our routine to ensure their accuracy
over time. If this effort is successful, everyone will benefit from a
definitive source of API documentation, the wiki can revert to being
entirely supplemental and non-definitive.
B.
On 13 July 2011 17:48, Jens Alfke <je...@couchbase.com> wrote:
>
> On Jul 13, 2011, at 1:03 AM, Robert Newson wrote:
>
>> We changed the format between releases. As noted, this is not part of the public API.
>
> Actually no one had said in this thread that open_revs isn't public API. :/
> Shall I remove the references to it from the wiki (both with ‘all’ and with a revision list?)
>
> Going forward it might be useful to adopt a special naming convention for new parameters that are for internal use only, like an “i_” prefix.
>
> —Jens
Re: Unexpected response for ?open_revs=all
Posted by Jens Alfke <je...@couchbase.com>.
On Jul 13, 2011, at 1:03 AM, Robert Newson wrote:
> We changed the format between releases. As noted, this is not part of the public API.
Actually no one had said in this thread that open_revs isn't public API. :/
Shall I remove the references to it from the wiki (both with ‘all’ and with a revision list?)
Going forward it might be useful to adopt a special naming convention for new parameters that are for internal use only, like an “i_” prefix.
—Jens
Re: Unexpected response for ?open_revs=all
Posted by Robert Newson <rn...@apache.org>.
We changed the format between releases. As noted, this is not part of
the public API.
This is yet another reason to have official docs in the couchdb source
tree, we can be sure that it only documents supported parts of the
API.
The ?conflicts=true parameter should be used here instead.
B.
On 13 July 2011 02:38, Jens Alfke <je...@couchbase.com> wrote:
> I’m trying to get a list of conflicting revisions by using the “?open_revs=all” query parameter, as described in the conflict documentation in the wiki[1]. But when I test this with curl, the output is completely unexpected — instead of a JSON array as documented, I get a MIME multipart body. What’s going on?
>
> In this example the document isn’t actually in conflict, as I haven’t synthesized a conflict in my test database yet (though I will soon thanks to Paul’s handy Python script!)
>
> $ curl -i 'http://127.0.0.1:5984/db/3aaa5e74e5d96db3b2248fb1c404eb65?open_revs=all’
> HTTP/1.1 200 OK
> Transfer-Encoding: chunked
> Server: CouchDB/1.2.0a-eb77a97-git (Erlang OTP/R14B01)
> Date: Wed, 13 Jul 2011 01:16:36 GMT
> Content-Type: multipart/mixed; boundary="5316aac5e82bfd1b98ba15d212819f24"
>
> --5316aac5e82bfd1b98ba15d212819f24
> Content-Type: application/json
>
> {"_id":"3aaa5e74e5d96db3b2248fb1c404eb65","_rev":"7-7e833e1c2ee3db8e4ae3f615c20ca592","first":"Jens","last":"Alfke","email":"jens@mooseyard.com"}
> --5316aac5e82bfd1b98ba15d212819f24—
>
> —Jens
>
> [1] http://wiki.apache.org/couchdb/Replication_and_conflicts