On Mon, Jul 11, 2011 at 3:11 AM, Mark Hahn <[email protected]> wrote: >> you could make one single class (ClassToRuleThemAll, let's say) to > hold the data for every single data type you work with, but that's silly. > > It's silly because there is a practical disadvantage in that every > instance would waste space for all the variables that would be needed. > > I can't think of any practical advantage for having multiple design > docs unless multiple apps share a db.
CQS uses multiple design documents which are machine-generated. https://github.com/iriscouch/cqs You get common access controls, but each queue can be created, modified, or deleted independently, without affecting the others. In my deployments, each worker has two queues (2 ddocs), high-priority and low-priority. Indeed, the real "application" is a distributed service, built from multiple workers, performing a common task. I am not satisfied with this architecture. It bothers me to know that dozens of validation functions execute for each update. Also, if I change the design doc code, I must re-deploy dozens of times. Changing validate_doc_update() code is a nightmare. But ultimately, it is a trade-off and I still feel the benefits outweigh the limitations. -- Iris Couch
