Commits on Jul 24, 2018

1. feat(schema) add eq validator …

   Does what it says: value must be equal to the given one:
   `{ foo = { type = "integer", eq = 42 } }` will force the "foo"
   field to be always 42.
   
   This looks like a weird validator to have, but it's going to come in handy
   when we define in a plugin subschema that the Consumer field must be `eq =
   ngx.null`, properly wrapped in a `typedefs.no_consumer` to replace the
   ad-hoc `no_consumer = true` feature of the old schema library.

   

   hishamhm committed Jul 24, 2018
   Copy the full SHA

   0a62ce3 View commit details

   Browse the repository at this point in the history

2. feat(schema) add support for subschemas …

   This resolves three difficulties that would appear when porting the Plugins
   entity over to the new DAO: loading the plugin configuration schema
   dynamically, the fact that this schema depends on a value of the entity row itself,
   and the fact that the specific plugin type can impose further constraints on
   values.
   
   The old DAO implemented this by allowing records to have a `schema` field that
   would be either a table or a function evaluated at validation time, and using
   an ad-hoc validation that checked for a `no_consumer` field to restrict the
   value of `consumer_id` to `null`.
   
   The new DAO implements this by allowing an entity (such as Plugins) to declare
   that it is extensible via **subschemas**:
   
   * a schema may declare that it allows subschemas, tagged by one specific
     string key of the schema, with the top-level `subschema_key` property.
     * essentially, the set of all plugins taken as one works like a tagged union.
     * for Plugins, `subschema_key` will be `"name"`
   * a schema may declare where it gets subschemas from, with the
     `subschema_module`.
     * for Plugins, `subschema_module` will be `"kong.plugins.?.schema"`
   * the parent schema may declare fields as "abstract", which are meant to be
     specialized by the subschema. Abstract records don't need their `fields`
     property to be set, and they must be given in the specialized ones.
     * for Plugins, `config` will be `abstract`
   * the set of fields considered when validating an entity is that of the
     parent schema
     * subschemas cannot introduce new fields, those need to be
       declared in the parent schema ("abstract" if needed)
     * the data model of strategies can be inferred from parent schema alone
   * subschemas may override both abstract and non-abstract fields.
     * they cannot change the type of a field
     * a field declared in the subschema overrides the parent schema's field
       completely (constraints are not merged)
     * for Plugins, plugins will override `config`, and for the `no_consumer`
       feature, they can override `consumer` using the `eq = null` validator

   

   hishamhm committed Jul 24, 2018
   Copy the full SHA

   86179f9 View commit details

   Browse the repository at this point in the history