Open shuttle1987 opened 5 years ago
Currently the schema only ensures values you set are correct.
It doesn't ensure values without defaults are provided. It wouldn't take much to convince me that it ought enforce that.
In this particular instance we want to make sure that every one of these items is present with the exception of the modified
field that may not be there.
I guess our need is some way to make sure that all fields we wanted to be present are actually there, and we have the notion of an optional field, like the modification date field that may be missing but has to be a DateTime if it's there. If someone supplies a None
for the modified time here I suspect this passes validation?
If there was a change that introduced that lets you enforce that the values have to be there it would be nice to have some way of marking that the values could be optional. If there's no enforcement then it would be nice to have some optional way of making sure that a field is present and valid.
So I'm experimenting with adding this, and my tests [oh wow, I have tests, don't I? :) ] show my original intention was that the error would raise if you accessed a no-default attribute without a value.
This is conflicting with the new approach.
From memory, I wanted the schema to act stand-alone, so you could instantiate a schema derivative, and then set its values. I'm not sure of how much utility this still is.
We currently have a
BlogPost
class that looks like this:We want to make sure a
posted
item (the post date) contains a proper datetime. The following contains noposted
however it seems to pass through the validation with no issues:Is there something we are getting wrong in our
BlogPost
definition here?