couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johs. E" <>
Subject CouchDB _rewrite
Date Fri, 04 Sep 2015 12:21:12 GMT
Fellow CouchDB enthusiasts,

Let me quote a dialogue I had the other day with a colleague on Couchapps and _rewrite:

> > I would like to know what is so horrible with the vhost/rewrite of CouchDB
> You must concentrate all rules in one place, that is totally out of idea ‘one app –
one ddoc’
> Capturing mechanics is outrageously ugly and limiting. You can‘t capture on query,
only on path, and in very limiting manner. Obsolete for at least 15 years.
> Rule lists are flat – they must be trees, since it‘s json, not SQL table of directory
with files.
> It‘s all very brittle, error prone and imposes all possible hurdles during debug –
no err messages, no log, no validator.
> And most important: it creates illusion, that it can fit everything – but it only fits
small static-like sites.
> > Is it something that could be fed to the developers?
> Don‘t think anybody of them is interested. This functions assumed obsolete or impractical
by the vast majority of community, as I see. And I agree with them.

Still with its limitations, I love _rewrite
You direct the vhost to db/_design/api/_rewrite
using so-called “unsafe” rewrites, you create an API for your many databases and their
couchapps there.
It works beautifully.
That is at Cloudant. I think I learned from an earlier discussion that the lack of a “default
vhost” is a problem outside Cloudant.
Now Cloudant does not offer SSL unless you enter into a relationship with your local IBM organization
and buy a dedicated cluster under a std IBM contract, so 

Of course I would like to see a better rewrite function, my priority would be
A tree structure of rules
Capture query in the “to”
That would be a great enhancement to go with version 2.0


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