Mango vdu

[jcoglan]

Overview

This PR implements "phase 1" of the functionality outlined in #5792, i.e. it adds the ability for validate_doc_update to be implemented as a Mango selector expression, rather than as a JavaScript function. The selector is evaluated against an ephemeral JSON structure containing newDoc (the new doc version to be saved) and oldDoc (the one currently on disk). For example, saving the following to /db/_design/mango-vdu will cause all docs to be checked for a type field which must be a string:

{
  "language": "query",

  "validate_doc_update": {
    "newDoc": {
      "type": { "$type": "string" }
    }
  }
}

This uses the existing infrastructure of couch_query_servers and mango_native_proc, just adding appropriate message handlers to Mango processes for handling VDU requests.

Testing recommendations

The added tests cover the basic functionality to check that Mango validators can be saved, and the in-memory cache is updated as appropriate. It assumes Mango works as it does in current releases and so does not re-test all the Mango functionality in detail.

Since there are now two different languages VDUs can be written in, I may have missed anything that assumes there's only one way to do it. I did however notice a counter being updated incorrectly, which is now fixed.

Related Issues or Pull Requests

• RFC: proposal for declarative VDUs #5792
• Additional Mango-based update handler / VDU functionality #1554

Checklist

• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• Documentation changes were made in the src/docs folder
• Documentation changes were backported (separated PR) to affected branches

[nickva]

This is fantastic, much smaller than expected. Nicely done, James!

[nickva]

I like the simple approach here, it turned out much simpler than expected implementation-wise at least!

If we're going to merge it, let's add some basic docs for it. Even if just API updates, but an example or two can be nice as well.

[janl]

I was going to give documenting this a short and when I looked where it would best fit in the docs, I realised that for Mango we have an API for adding indexes on top of the bare design doc mechanism.

I am wondering if we want to do this here as well, something along the lines of:

• GET /db/_vdu/ lists all VDUs in a list of ddocname/vduname
• PUT /db/_vdu/[ddocname]/vduname {…} to create/update a VDU, if ddocname is missing on create, use a random id, if missing on update: failure.
• DELETE /db/ddocname/vduname to delete a vdu, and delete ddoc if last vdu in ddoc and is otherwise empty

I’m not sure I’m super a fan of this, but it would be mirroring the other Mango API.

[nickva]

I’m not sure I’m super a fan of this, but it would be mirroring the other Mango API.

Yeah it makes sense from the Mango API pattern point of view, but selectors are sort of their own thing are used outside of Mango indexing already (filters), and VDU already exist (in JS form) and have their own "shape" so to speak and, at least to me, this seems more of an improvement/extension of the JS vdus.