[
https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793264#action_12793264
]
Joscha Feth commented on COUCHDB-604:
-------------------------------------
The more options, the more possible errors, yes - but making the client fixing
the validity of the response still seems a little weird.
A client which parses line-by-line can still strip the JSON header (which is
always the first line and the same length btw.) and disregard any leading
commas easily, because such a client interpretes each changes entry anyways -
whereas a different parser working on the overall stream or a client which just
wants all changes in the last X seconds and waits for the timeout has more
problems making the response valid afterwards.
But I agree it simplifies the process for some if it is readable line-by-line,
so this might just be one of the cases where an option just is necessary (don't
understand me wrong, I would also be fine if valid JSON output is the only
default).
> _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.
