couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Post on Trigger
Date Thu, 19 May 2016 13:06:08 GMT

the easiest way to build this today is with a CouchDB External:
that listens to a _changes feed.

You can use changes feed filters (
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.


> On 19 May 2016, at 13:49, Reddy B. <> 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
> 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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message