You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Reddy B." <re...@live.fr> on 2016/05/19 11:49:58 UTC
Post on Trigger
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
Re: Post on Trigger
Posted by Johs Ensby <jo...@b2w.com>.
Hi Freddy,
you are pushing for a feature that I think would fall into a category that earlier discussions on this list pushed aside to a separate list, couchapp@couchdb.apache.org
I would asume it to be a ' "no-go" for design of philosophical reasons' as you put it based on these discussions.
However it can be done, I did it this way
-- the _rewrite interface of the new release let you define rewrite rules as javascripts functions (make your own API server if you like) http://docs.couchdb.org/en/1.6.1/api/ddoc/rewrites.html <http://docs.couchdb.org/en/1.6.1/api/ddoc/rewrites.html>
-- your own api can include calls to other endpoints http://docs.couchdb.org/en/1.6.1/config/http-handlers.html#global-http-handlers <http://docs.couchdb.org/en/1.6.1/config/http-handlers.html#global-http-handlers> and include thinks like the users IP address, user id etc
-- OS Daemons http://docs.couchdb.org/en/1.6.1/config/externals.html <http://docs.couchdb.org/en/1.6.1/config/externals.html> keep a node.js running in the background that can do anything you want
-- procedures or recipies for what to do, you can store as JSON in the database
-- these procedures can be promise chains that call your CouchDB several times to compose e.g. a report or perform a batch job, do things like extrenal content scraping or lookups before calling your message service to deliver the report nicely wrapped in a html template.
-- your triggers can be acted on by a daemon looking at _changes http://docs.couchdb.org/en/1.6.1/api/database/changes.html <http://docs.couchdb.org/en/1.6.1/api/database/changes.html>
So this way you can customize the frontend and the backend to fit your needs. By making the node.js daemon very general and keeping all the variable stuff as JSON data, the node.js installation can go with your standard server image and you have your entire system on one platform, CouchDB, which is extremely convenient given its replication functionality.
br
johs
PS
I recommend this tool for design document programming: http://ddoc.me/ <http://ddoc.me/>
> On 19. mai 2016, at 13.49, Reddy B. <re...@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
>
RE: Post on Trigger
Posted by "Reddy B." <re...@live.fr>.
Wow shame on me, many apologizes for the delay in my reply.
@Harry
Thanks a lot for the pointer, I didn't know that I was able to hook into the datbase-change event, I definitely need to read more about the changes API, this is an interesting way to look at the problem.
The reason I wanted to use curl was to send a request to an external endpoint. Let's say, server A is the application server, and couch is on server B. When a certain type of change is made to a certain type of document, I want a certain POST request to be made to a certain server C who will know what to do with it - to keep couch focused on data. I'm thinking of a situation where there are a number of servers both in the application and the database layer (but only the fact that there would be a number of servers in the application layer, some of them having a specific purpose is relevant here).
I thought it could be interesting that Couchdb be directly able to do that, so that provisioning database servers is easier since there would only be CouchDb to install, and replication would allow to share the "script" containing the database call to be made easily between servers.
However if I need to poll the changes feed, I guess I'm back to square one since my objective was to avoid polling. But here I will need to look at the documentation first :)
@Johs
Thanks a lot for sharing this, this is gold !Even though I'm using CouchDb in a 3-tiers infrastructure (we're not ready for couchapps - yet ! - as a business), and I don't like mixing concerns and putting application logic in the database - things like POST triggers are as far I'm ready to go - for now :) -I can see that besides these details there are two bottom lines in what you say : either enhancing the CouchDb API to fit my needs, or running an OS daemon and keeping the configuration stuff as JSON to take advantage of the replication features of Couch (hopefully I understood your point properly).
The first one seems like an overkill I'm afraid considering my modest needs, and the second one takes me back to polling the changes feed (the point it to avoid polling) and making node provisioning a bit more difficult :/ (But besides that, you opened my eyes on possibilites for other matters that I find really cool). I'll keep studying this 2nd point: if I can reuse this Node.js thing for other purposes and end up with only CouchDb + Node.js in an image to suit all my needs, it might be worth it ! (But while the need doesn't go beyond these triggers, I think it would make the architecture overly complex to win almost nothing and I'd probably better stick to background jobs in the application layer).
Thanks again for these ideas !
@Jan
Thanks a lot Jan, this looks intriguing but extremely cool. I'm not sure it would help me on this particular issue based on what I said previously but it definitely opens up some perspectives, and help approach this class of problems from a different perspective.
> Date: Thu, 19 May 2016 14:24:11 +0200
> Subject: Re: Post on Trigger
> From: haraldkisch@gmail.com
> To: dev@couchdb.apache.org
>
> Hi Reddy,
>
> your request seems to be possible for me without any change to the CouchDB
> code.
> But you may need to think in another way. For me a trigger is nothing else
> than a change of a document.
> On database-change event you can easily trigger any other script in
> dependence whether a attribute in the changed document exists or not.
> Also a view index will be updated any time a new document is stored into
> CouchDB.
> Why you want to call curl behind the scenes is not transparent to me.
> For me which urls are called in the background depends on which domain
> (dev.url, stage.url, www.url) the app was deployed.
> But it could be that I misunderstand your request. Maybe you can make it
> more clear to me what you especially want to reach?
>
> Cheers,
> Harry
>
> On Thu, May 19, 2016 at 1:49 PM, Reddy B. <re...@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
> >
>
>
>
>
> --
>
> Dipl.-Inf. Harald R. Kisch
>
> Auenstraße 14
> 80469 München
> Germany
>
> Tel: +49 (0) 89 41 61 58 57-6
> Mobil DE: +49 (0) 176 56 58 58 38
>
> Skype: harald.kisch
> Mail: haraldkisch@gmail.com
Re: Post on Trigger
Posted by Harald Kisch <ha...@gmail.com>.
Hi Reddy,
your request seems to be possible for me without any change to the CouchDB
code.
But you may need to think in another way. For me a trigger is nothing else
than a change of a document.
On database-change event you can easily trigger any other script in
dependence whether a attribute in the changed document exists or not.
Also a view index will be updated any time a new document is stored into
CouchDB.
Why you want to call curl behind the scenes is not transparent to me.
For me which urls are called in the background depends on which domain
(dev.url, stage.url, www.url) the app was deployed.
But it could be that I misunderstand your request. Maybe you can make it
more clear to me what you especially want to reach?
Cheers,
Harry
On Thu, May 19, 2016 at 1:49 PM, Reddy B. <re...@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
>
--
Dipl.-Inf. Harald R. Kisch
Auenstraße 14
80469 München
Germany
Tel: +49 (0) 89 41 61 58 57-6
Mobil DE: +49 (0) 176 56 58 58 38
Skype: harald.kisch
Mail: haraldkisch@gmail.com
Re: Post on Trigger
Posted by Jan Lehnardt <ja...@apache.org>.
> On 19 May 2016, at 18:03, Matthew Rijk <mr...@gmail.com> wrote:
>
> How can i unsubscribe to this feed
This is the documentation: http://docs.couchdb.org/en/1.6.1/api/database/changes.html
Best
Jan
--
>
> On Thu, May 19, 2016 at 9:06 AM, Jan Lehnardt <ja...@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. <re...@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/
Re: Post on Trigger
Posted by Jan Lehnardt <ja...@apache.org>.
Wow, did I misread that message ;D
Sorry!
Best
Jan
--
> On 19 May 2016, at 23:27, Andy Wenk <an...@apache.org> wrote:
>
> Matthew,
>
>> On 19 May 2016, at 18:03, Matthew Rijk <mr...@gmail.com> wrote:
>>
>> How can i unsubscribe to this feed
>
> sorry to see you go. Please send an email to dev-unsubscribe@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 <ja...@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. <re...@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/
Re: Post on Trigger
Posted by Andy Wenk <an...@apache.org>.
Matthew,
> On 19 May 2016, at 18:03, Matthew Rijk <mr...@gmail.com> wrote:
>
> How can i unsubscribe to this feed
sorry to see you go. Please send an email to dev-unsubscribe@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 <ja...@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. <re...@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/
>>
>>
Re: Post on Trigger
Posted by Matthew Rijk <mr...@gmail.com>.
How can i unsubscribe to this feed
On Thu, May 19, 2016 at 9:06 AM, Jan Lehnardt <ja...@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. <re...@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/
>
>
Re: Post on Trigger
Posted by Jan Lehnardt <ja...@apache.org>.
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. <re...@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/