Support _changes (patch included)

[GoogleCodeExporter]

The attached file allows for using the _changes request which can't be done
using any of the existing Database methods.

Original issue reported on code.google.com by rogerbinns on 2 Dec 2009 at 4:56

Attachments:

• couchdb-changes.py

[GoogleCodeExporter]

This would work for normal and longpoll feeds but not for continuous. 

However, a continuous feed is quite different - it's streaming (httplib2 
doesn't do 
streaming) and it doesn't return a valid JSON document - so perhaps that should 
have 
its own API anyway.

Original comment by matt.goo...@gmail.com on 2 Dec 2009 at 6:15

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

If you also wanted continuous support then this API would need to be callback 
based.
 However that does lead to further problems - for example on Ubuntu CouchDB is
shutdown and restarted across suspend/resume so any connection to _changes get
various networking errors.  A callback based approach would need to 
transparently
handle that internally.  The code I give punts that back to the API user.

Original comment by rogerbinns on 2 Dec 2009 at 7:32

[GoogleCodeExporter]

Callback-based is one way, and probably the nicest, although something iterable 
with a 
.close() method would also work.

Any connection, especially something like a long-lived feed=longpoll, may get 
network 
errors. No need for a changes API to worry about that at all - just throw the 
error 
back at the user and let them decide. It's a fact of network of connections 
that they 
can be cut off at any time.

Original comment by matt.goo...@gmail.com on 2 Dec 2009 at 7:37

[GoogleCodeExporter]

I think I'd prefer a generator with a close method, I think it's cleaner 
(because the
control flow is clearer) than a callback-based API.

Original comment by djc.ochtman on 9 Dec 2009 at 10:12

[GoogleCodeExporter]

I was working on some _changes code earlier and wanted to improve it so I 
started looking at 
how I could get it into python-couchdb at the same time.

Unfortunately, I can't see any way to implement feed="continuous" without:

1. Bypassing httplib2, i.e. drop down to httplib.
2. Reading 1 byte at a time (yuck!) OR
3. Going async and re-implementing some of the response reading code, including 
chunked 
transfer encoding.

Even 3, the cleanest option IMHO, means digging around in the private internals 
of the 
httplib connection.

I'm not sure if the experimental httplib would help here, but I suspect not as 
it too is 
built on httplib and that's really where the problem lies.

Perhaps I'll put together a patch and see if people think the level of hackery 
is worth it.

Original comment by matt.goo...@gmail.com on 13 Dec 2009 at 9:13

[GoogleCodeExporter]

Non-continuous changes support added in r93a8f2acd2c2.

Original comment by djc.ochtman on 24 Dec 2009 at 11:16

[GoogleCodeExporter]

I've added support for feed=continuous in r0fb1c34db9b2.

Original comment by djc.ochtman on 29 Jan 2010 at 3:25

• Changed state: Fixed