couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johs Ensby <j...@b2w.com>
Subject Re: Post on Trigger
Date Thu, 19 May 2016 12:42:07 GMT
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. <reddy.b@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
> 		 	   		  


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