Multiple validate_doc_update functions in CouchDB design documents. Any good practices?

After reading this paragraph in the CouchDB Definitive Guide (here):

If you have multiple design documents, each with a validate_doc_update function, all of those functions are called upon each incoming write request. Only if all of them pass does the write succeed. The order of the validation execution is not defined. Each validation function must act on its own.

I'm wondering if there is any good practice to deal with multiple validate_doc_update function ?

I mean: Is it better to create only one design docu开发者_JS百科ment with a validate_doc_update field or having several smaller ones?

In the first case, one can be sure that none of the validation functions will interfere with another, but the function may become very large if a lot of controls are needed.

On the other side, several smaller functions may be easier for reading purposes and evolutions, but one have to be sure of the purpose of each function and not mess with other ones.

Plus, what's the point of letting each design document hold a validate function? Storing one in a view document seems a bit dirty for instance, but creating several design documents just for the intent of holding one small validation function doesn't seems very clever to me either.

What do you think?

I may have missed something, that's the point of my question, is there any good practices about the management of multiple validate_doc_update function?

Note, I wrote the quoted paragraph.

In general, I'm seeing a 1:1 correlation between applications and design docs. Everything a single application needs should be in one design document. Bigger applications may want to rely on multiple design docs for various reasons (like different groups of views), but in general, one design doc per app is a good rule of thumb.

Now, you may have multiple applications per database. E.g. a CMS: one application could be the public facing CMS viewing app and another one would be the admin interface. You want to keep them separate because, well, they are two distinct apps that operate on the same data and keeping them separate is a good organisational idea. Different security mechanisms apply, so you have two validation functions that do implement what is applicable for the respective app.

The quoted paragraphis the definition of the case where you do have (for whatever reason) have more than one design document per database. It explains what to expect. It is not meant as a guideline how to split things up. Go with the one design doc per app rule of thumb and you're good most of the time.

I know there has already been an answer selected, but I will at least throw out my practices regarding the matter as an alternative.

I have decided against just building pure CouchApps, at least for the time-being. (I have decided on Node.JS as my new middleware layer) With that in mind, I get a lot more flexibility out of CouchDB Design Documents.

I have moved toward having a separate Design Document for each entity in my database. As a result, each design document contains it's own views, validation functions, update handlers, etc. In response to your question, each validation function deals with only 1 entity in my database, which makes it more focused and easier to manage.