couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reddy B. <>
Subject Post on Trigger
Date Thu, 19 May 2016 11:49:58 GMT

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.


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