readonly conflicts with default

[dkellner]

Used Cerberus version / latest commit: 1.0.1 / ebd281b

• I consulted these documentations:
  • http://docs.python-cerberus.org/en/stable/
  • http://docs.python-cerberus.org/en/latest/
• I consulted these sections of the docs to see if there is any mention of this behaviour or any warning about using them together:
  • readonly
  • default
• I found nothing relevant to my problem in the docs.
• I found the documentation not helpful to my problem.
• 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.

---

Bug report

Documents always fail validation when default and readonly are used on the same field.

This is because default value handling / normalization will happen before the readonly validator is called and the latter will therefore always fail, because the document will always contain the field. I think we should allow validators to be processed before normalization and maybe another list like priority_validations for those rules would be useful.

I've started working on this already, but of course any comments are appreciated :).

Failing test

    def test_readonly_field_with_default_value(self):
        schema = {
            'created': {
                'type': 'string',
                'readonly': True,
                'default': 'today'
            }
        }
        self.assertSuccess({}, schema)
        self.assertFail({'created': 'tomorrow'}, schema)
        self.assertFail({'created': 'today'}, schema)

[funkyfuture]

well, yes. they are conflicting. by definition. it's okay.

nothing hinders you to run various validations and normalizations in any arbritrary order. i would even suggest that this is a good practice when schemas are getting complex.

[dkellner]

I've encountered this issue because I'm integrating Cerberus 1.0 in Eve: https://github.com/nicolaiarocci/eve/issues/776

Eve currently has its own default-rule supporting the combination with readonly with the behaviour described by the test above. Of course we can always discuss about dropping a corner-case feature like this, but in this case I would update docs and maybe even let the schema validation fail.

---

I have some working code allowing default and readonly already. In a nutshell, the needed change is the following. Right now we are doing two "steps" (in validate with normalize=True):

1. Normalization of the complete document, incl. subdocuments
2. Validation of the complete document, incl. subdocuments

If we want to have fields with both readonly and default, we have to do:

1. Validation, but just process only readonly-rules and ignore the rest (but still recursing down all subdocuments, because normalization will do the same!)
2. Normalization
3. Validation of all rules except readonly

If you are interested, you can see the code here: https://github.com/dkellner/cerberus/tree/default-readonly. There is still one failing test, because the first validator (processing "only" readonly) needs to run the recursing rules like items and schema etc. too, but they not just recurse but can fail by themselves, too. But I did want to hear your thoughts first before investing more time on this.

So the important question is: Do we want to allow default and readonly on the same field? In this case I would clean up my code, do some further refactoring and create a PR. If not, I will at least update the documentation and create a PR, too.

---

One further question to your "good practice"-suggestion: Do you mean running a validator with just read-only checks and allow_unknown=True first, and then running another validator with normalization and the other stuff? I guess this would work, but I kind of like having just one schema describing how my data looks like.

[nicolaiarocci]

Do we want to allow default and readonly on the same field?

My answer would be Yes.

[funkyfuture]

i'm not sure if I understand the use-case from the tests above. but wouldn't it suffice to update the document with the default values in the client code before it is processed by cerberus?