couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: How exactly are you using CouchDB?
Date Sun, 26 Jul 2015 16:22:19 GMT
Hi Joel! Welcome! (:

On Sun, Jul 26, 2015 at 6:50 PM, Joel Wallis <> wrote:
>    - *Document CRUD control:* I know there are design documents which make
>    it possible to create validation documents, but the code is stored on
>    database. How do you control the lifecycle of the code (track it with a
>    VCS, code, test, debug, etc.)?

When I develop laboratory information system integration service on
CouchDB, I used the following principle:
- Each design document is a couchapp and controls specific domain with
no cross references;
- Each couchapp stores within own repository;
- Code of them is the same as for regular ones;
- Testing happens in two ways: functional and integrational.  With the
last one everything is clear - you just have a client that calls API
and checks if everything is fine. First one was more interesting and
ran right on CouchDB via special show function call and mocked query
server behind. So I was able to verify service status at any time;
- Deploy happened in usual for couchapps way to dev and next via
replications to prod. There was no release cycles and it was live
development all the time what made feature delivery possible just in
- Debug happens with the proper test suite and record-replay of request objects;

>    - Also, is there any way to make *CouchDB read a view code from file
>       system instead of a document?*


>       - *Access control level:* there are user/password authentication,
>    with optional roles usage, but how can I store "private" documents - like
>    documents that are accessible for some role?

Database-per-user pattern rules here. Databases are cheap, so just put
the data which should be read by only some specific group of users
into separate database.
See also:

>    - *"Cron tasks":* is there any way to implement tasks that need to be
>    executed frequently, like data integrity, math operations, cache
>    invalidation, or some kind of task that really need to be done periodically?

CouchDB has a feature called "os_daemons": it's a special processes
which are spawned and supervised by CouchDB. They can communicate with
CouchDB via stdio protocol and do some work in background. For
instance, cron tasks, data checks or even provide own service. Read
more about here:

>    - What are the *best practices for CouchDB based development?* And if
>    there's some, why its not on CouchDB Docs yet? :)

Best practices are depends on task, overall experience and what tools
you're going to use. I have my own set, but I know that they may not
be applicable for some other case.  There certainly is some golden
rules, but I would prefer to not focus on them, but seek the set of
practices that makes solve my problem at the best with minimal
resources. So I wish to you (:

Having anything about in docs is good, but it's long discussing topic.

Hope this helps.


View raw message