Wow, did I misread that message ;D Sorry!
Best Jan -- > On 19 May 2016, at 23:27, Andy Wenk <andyw...@apache.org> wrote: > > Matthew, > >> On 19 May 2016, at 18:03, Matthew Rijk <mrij...@gmail.com> wrote: >> >> How can i unsubscribe to this feed > > sorry to see you go. Please send an email to > dev-unsubscr...@couchdb.apache.org with the email address you are subscribed > with. > > All the best > > Andy > -- > Andy Wenk > Hamburg - Germany > RockIt! > > GPG public key: > https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D > >> >> On Thu, May 19, 2016 at 9:06 AM, Jan Lehnardt <j...@apache.org> 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. <redd...@live.fr> 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/ >>> >>> > -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
signature.asc
Description: Message signed with OpenPGP using GPGMail
