How can i unsubscribe to this feed On Thu, May 19, 2016 at 9:06 AM, Jan Lehnardt <[email protected]> wrote:
> 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/ > >
