Hi Joel! Welcome! (: On Sun, Jul 26, 2015 at 6:50 PM, Joel Wallis <[email protected]> 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 time; - 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?* Check: https://github.com/couchapp/couchapp https://github.com/benoitc/erica > - *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: https://github.com/etrepum/couchperuser > - *"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: http://docs.couchdb.org/en/1.6.1/externals.html > - 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. -- ,,,^..^,,,
