Heya, the easiest way to build this today is with a CouchDB External: http://docs.couchdb.org/en/1.6.1/externals.html that listens to a _changes feed.
You can use changes feed filters (http://docs.couchdb.org/en/1.6.1/api/database/changes.html) to get the “only when a doc is emitted” type of event you mention (or you filter that in your external script). From the script then you can do whatever you want. A CouchDB External is started and stopped (and kept alive) by CouchDB itself, so you are saving yourself the effort of a system integration startup script. Best Jan -- > On 19 May 2016, at 13:49, Reddy B. <[email protected]> wrote: > > Hi, > > I am fairly new to CouchDb and loving it so far. I think this database is > shockingly underated. I love the "Relax" approach and the design choices > that have been done, and I hope things will continue with the same philosophy. > > I couldn't find if this has been discussed before but I was thinking that it > would be extremely cool to be able to setup triggers that POST arbitrary json > to arbitrary endpoints. I think this would be a killer feature if there was > built-in support for that - and seems to fit well with the HTTP approach of > couch. > > So basically, this would be about allowing us to add an arbitrary number of > triggers to any view. Each trigger would be called only if the view emitted > "something" and the trigger would receive the document passed as a parameter > to the view (this is to take advantage of the update frequency of views) Then > in terms of posting, there could be a new built-in javascript function > calling curl behind the scenes which can be called from the triggers. > > For the same purpose, it would be interesting to introduce configuration > documents at the database level whose properties could be accessed from these > triggers (I'm thinking of situations when one would need to call a different > URL when in testing, staging, production etc...) > > In terms of use case, this would allow us to do things as diverse as sending > email notifications, and maintenance tasks. More generally, this would > eliminate the need for most of the maintenance jobs out there while making > these systems much more efficient by removing the need to run jobs at > arbitrary times even when this is not necessary. Also, since most web > frameworks are asynchronous and process each request in a different thread, > this would be a way to easily parallelize certain operations. > > I just wanted to know if there was any chance to see this come out one day or > if this would be a "no-go" for design of philosophical reasons. > > Cheers, > > Reddy > -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
