CouchDB - managing design documents?

Tony Atkins tony at
Mon Aug 28 11:32:23 UTC 2017

Hi, Alan:

Thanks again for starting yet another interesting and important
discussion.  I've had to do a lot of this in my own work, and have
alternated between:

   1. Storing the design documents as raw JSON (mainly for testing).  This
   is similar to the approach used in the example you shared.
   2. Writing design documents using couchapp

The first approach seems easy enough, but is a bit tedious on a few fronts:

   1. It's difficult to write even moderately complex functions as escaped
   2. Replacing an existing design document is a bit tedious, as it
   involves either looking up the current document's _rev or DELETEing and
   then POSTing the replacement.
   3. Although it's possible to require libraries from a design document
   this is pretty hard to manage using raw JSON files.

Couchapp makes each of these easier:

   1. You just save your functions to a file, which you can run through our
   standard linting and more easily check for syntax errors.  You can even
   write unit tests against the functions you plan to use in your design
   documents.  This is especially helpful when developing reduce functions,
   which can be a bear to troubleshoot with CouchDB or PouchDB.
   2. Although it's trivial, couchapp makes it very easy to update design
   docs repeatedly.
   3. Couchapp makes it easier to bundle dependencies as part of your
   design document (basically by deploying them to a "lib" or similar
   directory within a design document's directory).

That being said, couchapp is something I have only relied on reluctantly.
I don't use it in tests, for example, as it seems a bit much to me to
introduce a whole stack of dependencies (python, required libraries) just
to solve what's a fairly simple use case.  Antranig and I have previously
talked about building a Fluid component to assist with creating design
documents, and it seems like a good time to broaden and refresh that

Regardless of whomever else is interested, I would be very happy to work
together with you (and I'm assuming Antranig) on a ticket outlining the use
cases in more detail.  Depending on the scope of what we agree is needed, I
might end up simply building it the next time I need to work on a batch of
design documents.  I'd also be very happy to help review something someone
else builds and test that in my own work.



On Thu, Aug 24, 2017 at 4:16 PM, Harnum, Alan <aharnum at> wrote:

> Hi all,
> We (Greg Moss & myself) are curious to know the opinions of others who've
> worked with it (especially in the context of Infusion / Kettle) about how
> to best manage design documents when using CouchDB as part of an
> application.
> Specifically, what approaches have worked for externalizing design
> document code, ensuring the database has the latest design document code,
> etc?
> I know one example of doing this is in gpii-oauth2-datastore, which is a
> JSON externalization of the views that is imported to the DB as part of
> application provisioning, described at:
> iversal/tree/master/gpii/node_modules/gpii-oauth2/gpii-oauth
> 2-datastore/dbViews
> I am wondering if people have seen or considered other approaches.
> My own feeling is that it would be useful to be able to model an expected
> CouchDB database design document as an Infusion component, with the
> component taking responsibility for ensuring a set of view functions are
> present in the specified DB, but I don't feel a great certainty about this.
> Curious as to the thoughts of others!
> Alan
> *E *aharnum at <//aharnum at>
> 100 McCaul Street, Toronto, Canada, M5T 1W1
> <>
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list