[
https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793202#action_12793202
]
Brian Candler commented on COUCHDB-604:
---------------------------------------
> By the way, XMPP works the same - it basically has an infinitely long stream
> of XML elements
> flowing - but still starts with a root node and ends with a closing one to be
> valid XML.
Stream parsing is much more common in the XML world; unfortunately JSON stream
parsers are not (yet?) widespread.
> You might call it a feature request, but I think either the output should be
> valid JSON or not.
> If you tell me the output is not valid JSON, okay, but I couldn't read this
> from the docs, as all
> other _changes interfaces return valid JSON.
It's not valid JSON, and I would agree it's a bug if you're referring to the
Content-Type header which is returned:
$ curl -v -H "Accept: application/json"
http://127.0.0.1:5984/test_suite_db/_changes?feed=continuous
...
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Server: CouchDB/0.11.0a813819 (Erlang OTP/R12B)
< Date: Mon, 21 Dec 2009 13:35:52 GMT
< Content-Type: application/json
< Cache-Control: must-revalidate
<
I would also agree that it's inconsistent with the way a view is returned.
Views are complete JSON docs, but have newlines in magic places to make it
possible to parse them line-at-a-time.
$ curl -H "Accept: application/json"
http://127.0.0.1:5984/test_suite_db_a/_all_docs
{"total_rows":5,"offset":0,"rows":[
{"id":"6d85c1ca41bd9eb4435b2fcac3670b84","key":"6d85c1ca41bd9eb4435b2fcac3670b84","value":{"rev":"1-d4388236888cf366f37777e888221968"}},
{"id":"927c96f86e2fdebbcae3520ac2054fbd","key":"927c96f86e2fdebbcae3520ac2054fbd","value":{"rev":"1-d4388236888cf366f37777e888221968"}},
{"id":"bar","key":"bar","value":{"rev":"6-7c014f6deb5cd9935625a8f411f8db08"}},
{"id":"c134ca85221694a28f9ad8953b3087a7","key":"c134ca85221694a28f9ad8953b3087a7","value":{"rev":"1-d4388236888cf366f37777e888221968"}},
{"id":"foo","key":"foo","value":{"rev":"21-b94c260d79b638231eb14b3de8458c2f"}}
]}
It would have been possible for feed=continuous to work this way too.
In that case I'd have thought the comma should appear at the *start* of each
line (apart from the first, obviously), otherwise you need a dummy record at
the end to close the stream cleanly. And if you want the heartbeat feature
you'll still need a dummy record.
> _changes feed with ?feed=continuous does not return valid JSON
> --------------------------------------------------------------
>
> Key: COUCHDB-604
> URL: https://issues.apache.org/jira/browse/COUCHDB-604
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Affects Versions: 0.10
> Reporter: Joscha Feth
> Priority: Trivial
>
> When using the _changes interface via ?feed=continuous the JSON returned is
> rather
> a stream of JSON documents than a valid JSON file itself:
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]}
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true}
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]}
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]}
> to be valid there needs to be a root element (and then an array with commata)
> like in the non-continuous feed:
> {"results":[
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]},
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true},
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]},
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]},
> in short this means that if someone does not parse the change events in an
> object like manner (e.g. waiting for a line-ending and then parsing the
> line), but using a SAX-like parser (throwing events of each new object, etc.)
> and expecting the response to be JSON (which it is not, because its not
> {x:[{},{},{}]} but {}{}{} which is not valid) there is an error thrown.
> I can see, that people doing this line by line might be okay with the above
> approach, but the response is not valid JSON and it would be nice if there
> were a flag to make the response valid JSON.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
