Schema file not working anymore with Cerberus 1.3

[fdeschamps]

Used Cerberus version / latest commit: Cerberus 1.3 / Python 3.5.2

• I have the capacity to improve the docs when my problem is solved.

• I have the capacity to submit a patch when a bug is identified.

• My question does not concern a practical use-case that I can't figure out
  to solve.

---

Use-case abstract

Since Cerberus 1.3, keyschema and valueschema are deprecated and should still work, but I get an error when using them.

The error is gone when using the new keys keysrules and valuesrules.

Here is my schema :

requests:
  type: dict
  keyschema:
    type: string
  valueschema:
    type: dict
    schema:
      aggs:
        type: dict
        keyschema:
          type: string
        valueschema:
          type: dict

My Python code :

#!/usr/bin/env python3

from yaml import load, load_all
from cerberus import Validator

schemafile = "schema.yml"

with open(schemafile, "r") as f:
    schema = load(f)

v = Validator(schema)

And the Python error :

Traceback (most recent call last):
  File "./test.py", line 11, in <module>
    v = Validator(schema)
  File "/usr/local/lib/python3.5/dist-packages/cerberus/validator.py", line 181, in __init__
    self.schema = kwargs.get('schema', None)
  File "/usr/local/lib/python3.5/dist-packages/cerberus/validator.py", line 562, in schema
    self._schema = DefinitionSchema(self, schema)
  File "/usr/local/lib/python3.5/dist-packages/cerberus/schema.py", line 76, in __init__
    self.validate(schema)
  File "/usr/local/lib/python3.5/dist-packages/cerberus/schema.py", line 247, in validate
    self._validate(schema)
  File "/usr/local/lib/python3.5/dist-packages/cerberus/schema.py", line 263, in _validate
    raise SchemaError(self.schema_validator.errors)
cerberus.schema.SchemaError: {'requests': [{'valuesrules': [{'schema': ['no definitions validate', {'anyof definition 0': [{'aggs': [{'valueschema': ['unknown rule'], 'keyschema': ['unknown rule']}]}], 'anyof definition 1': [{'aggs': ['unknown rule']}]}]}]}]}

---

Bug report / Feature request

[funkyfuture]

it seems this has been fixed in #453. it would be helpful if you could verify it by testing the current master branch.

[fdeschamps]

I tested with the current master and it works. Thanks.

[sebix]

I had the same issue with version 1.3 and current master works fine again. Thanks for the quick solution!

Maybe a new bugfix release is possible so this fix reaches more affected parties?

[funkyfuture]

@nicolaiarocci what about publishing 1.3.1 around the end of the week, given there are no further bug reports, would that fit your schedule?

in the borgbackup repo they open an issue for each RC they publish where people can leave short feedback that they used it successfully. shall we try this?

[nicolaiarocci]

yep, I plan on releasing by the end of this week. Not sure on the feedback ticket: people will inevitably keep opening new tickets. Might be a good idea for a RC, not-so-good for actual releases methinks.

[WeatherGod]

+1, looks like I was obliquely hit by this (although I think my problem was partly dependent on having a meta entry as part of my dictionary schema). However, everything seems to work with master.

[nicolaiarocci]

howdy everyone, v1.3.1 has been released a few minutes ago.

[funkyfuture]

@WeatherGod just to be sure, the meta key was a custom rule, not a field name, right? otherwise it'd be seemingly a bug.

[WeatherGod]

Uhm, trying to make sure we have terminology correct. I think in this situation, my meta would be considered a field name. The dictionary schema was defined to have two keys, one called "sources" and the other called "meta".

[funkyfuture]

i'm even more confused now. simply asked: does your schema include keyschema or valueschema rule? with the now released 1.3.1, did you have to change your schema?

[WeatherGod]

yes, it does have keyschema and valueschema. No, I did not have to change my schema with master as of yesterday (I haven't tried the new release yet, though). Here is the relevant part of my schema and an example that satisfies it:

bundles:
    type: dict
    required: true
    valueschema:
        type: dict
        schema:
            sources:
                type: list
                schema:
                    type: string
                    empty: false
                coerce: to_list
                empty: false
                required: true
            meta:
                type: dict
                keyschema:
                    type: string
                    empty: false
                required: false
    keyschema:
        type: string
        empty: false

Example:

bundles:
    - foo:
        sources: some/path/*.txt
        meta:
            arbitrary: data

The config schema would fail using cerberus v1.3.0 with a SchemaError. If I comment out the "meta" section of the schema (and take out the "meta" section in the example), then everything worked in v1.3.0. Interestingly enough, other areas of my larger schema file also had "meta" fields in a schema rule, but those schema rules weren't within a valueschema, and cerberus v1.3.0 didn't complain about them.

[funkyfuture]

okay, now all makes sense. 42.

[WeatherGod]

so, you are satisfied that this is the same bug? If you are, then I am too.

[funkyfuture]

yes, thanks for your feedback.