Option to merge defaults

[jonasfj]

In JSON schema it's often useful for declare defaults, with the default value for an optional property. This is powerful for documentation, and many validators supports inserting the default into the validated object, this way you don't hardcode defaults into your code, but declare the defaults in your input schema.

Example A)

var Ajv = require('ajv');
var ajv = Ajv({mergeDefaults: true}); // Specify that we want defaults merged

var validate = ajv.compile({
  type: "object",
  properties: {
    myProp: { // optional property
      type: "string",
      default: "Hello World" // default value
    }
  }
});

var data = {
  someOtherProp: "another value"
};

validate(data); // true
console.log(data)
// {someOtherProp: "another value", myProp: "Hello World"}

This would be extremely useful, and doing this outside of the schema validation is hard, as you want to do this on all sub-objects as well, some of which may exist under an anyOf, so you can't insert the defaults until you're sure which anyOf branch is satisfied.

It's quite possible that this is a post processing step, as nested anyOf branches means you sometimes can't do this until after everything is validated. A possible work around might be to insert the defaults into a clone of the existing object, that way multiple anyOf branches shouldn't be a problem.

Note, this only really relevant for objects, but could also be done for arrays which has items: [{default: ...}, {default: ...}] (though this is a corner case). It doesn't really make sense to do this when the top-level schema type is a value type like integer as the input is either valid (ie. an integer) or invalid (ie. another type or null).

Remark, after inserting a default value, validator should validate the default value too. This should ideally be done a schema compile-time. It is important to do this, because the default value of a property which has type: 'object' may be {} and the schema for that object may specify properties for this that has additional default values. It would also be nice to get errors about inconsistencies at compile-time.

[epoberezkin]

I agree that it's a useful feature. The reason it is absent is the number of complex and/or contradictory scenarios that should be covered. I am sure that there will be other complications that we don't immediately see. The additional problem with anyOf, for example, is that multiple branches can be satisfied. allOf is also not obvious. Post processing is not going to work, because I think that the expectation is that if default is provided and the value is missing, object with inserted default should be valid, not without. Pre-processing is difficult because it is not clear which branches are going to be valid. Some validators implement complex scenarios with changes and roll-backs...

I will probably implement it at some point, but it's not a simple task. PR is welcome of course :)

[jonasfj]

One could probably forbid default under allOf branches... (I suspect allOf is rarely used too).
But to determine of anyOf can have multiple branches we would have to build static analysis tools for JSON schemas ... Wow, that got complex really fast :)

Or you define that you choose the first anyOf branch...

[epoberezkin]

The first valid anyOf branch I assume. So I guess apply defaults first (if it wasn't applied in the previous branch), validate a branch, rollback if it wasn't valid...

[jonasfj]

Roll back seems hard.. Perhaps it's simplest (and possibly cheapest) to create a new object and
return along with the result. That way you don't mutate the input object too...

[atrniv]

@jonasfj you might be interested in taking a look at the defaults implementation in Themis. One of the main reasons I wrote it was because of the lack of support for defaults in most existing validators. We've been using it in production quite successfully for quite a while.

@epoberezkin, It is not a simple solution to implement and it does have a significant performance impact but ultimately it provides a level of convenience which makes up for the shortcomings.

[epoberezkin]

@atrniv, thanks. I was actually thinking about implementation in themis.