couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Candler (JIRA)" <>
Subject [jira] Commented: (COUCHDB-604) _changes feed with ?feed=continuous does not return valid JSON
Date Mon, 21 Dec 2009 13:44:18 GMT


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/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"

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:
>             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.

View raw message