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 br Johs
