We had a similar problem. Initially we had each database replicate appropriate documents (via a replication filter) to a queue database and just listened for changes to that. The resource overhead for this when most databases are dormant didn't make make sense. So we now have a custom handler that invokes some python whenever a PUT, PUSH or DELETE occur to a subset of databases. I've put this up on GitHub - https://github.com/ocastalabs/couchdb_task_handler.
This handler is dependant on CouchDB including the document ID in the response headers which it currently doesn't so we had to make a small change to the CouchDB source. You can find this at https://github.com/ocastalabs/couchdb/tree/id_and_rev_in_response_headers. We've raised a Pull Request for this ( https://github.com/apache/couchdb/pull/32) and it would be great to get it into 1.3 Martin On 7 October 2012 11:37, svilen <[email protected]> wrote: > no worries, not that in a hurry. > i'll put some workaround in the mean time.. > still prototyping anyway. > > ciao > svil > > On Sun, 7 Oct 2012 12:18:29 +0200 > Benoit Chesneau <[email protected]> wrote: > > > On Sun, Oct 7, 2012 at 10:25 AM, svilen <[email protected]> wrote: > > >> On 7 October 2012 07:59, svilen <[email protected]> wrote: > > >> > g'day > > >> > > > >> > i'm going to have thousands of databases. They are all of similar > > >> > kind, but belong to different (groups of) users, so can't be > > >> > bundled into one. And setupping 10000 connections to > > >> > couchdb/dbXXXXX/_changes doesn't seem very neat, even if on same > > >> > machine. > > > > > > or maybe i can traverse all of them (i think i can figure out the > > > db names), paying them some limited attention each - e.g. use > > > short-poll with limit 10 changes.. poor-man's time-share > > > scheduler ;-) > > > > > > svil > > > > Well it will be costly, depending on the number of databases you have. > > If you need it fast you can use rcouch waiting that I port the code to > > couch. Can be done next week. > > > > - benoît >
