Add method for injecting defaults

[chuwy]

Following instance:

{"foo": 1}

Is valid against following schema:

{
  "type": "object",
  "properties": {
    "foo": {"type": "integer", "default": 0},
    "bar": {"type": "string", "default": "baz"}
  }
}

Though .validate method won't inject default value for bar. And I believe this is correct behavior. Instead we should have method like .setDefaults that when invoked mutates original JSON by setting missing bar (but not foo of course).

/cc @knservis

[alexanderdean]

.setDefaults is interesting. It makes schema backwards compatibility easier. What happens in JSON Schema if you have a default, make the field "required", but it's not present in the instance - presumably validation fails?

[chuwy]

Yes, validation fails at least at https://www.jsonschemavalidator.net/

[knservis]

Would you not run setDefaults before validate?

Also, should you not validate against the previous version of the schema anyway?

[chuwy]

This would be a good idea to call it before, but this is up to consumer.

Question here: should cases like required AND default be invalidated by one of optional igluctl linters? For me it looks like user doesn't quite understand what he wants.

[knservis]

At least a warning is warranted. Something like "WARN required AND default found for field x! Required is redundant!". An error is also an option if that definition will cause errors. The warning will alert the user to a possible omission, but the execution is possibly unaffected by removing required in the case that default is present. Either way is fine as the user needs to know that this is pointless.

[chuwy]

Yep. This is exactly how all linters work. If it sees type: string and maximum: X (integer's validation) - it yields. Schema is valid, validator can proceed, but this is very likely user missed something, usually just because he/she refactored schema and forgot something.

[chuwy]

I'm thinking this can be a separate enrichment.