-
Notifications
You must be signed in to change notification settings - Fork 240
clarifiy / rename readonly-rule #127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
oh, on a second thought, it isn't. like |
i pledge to resolve this before an 1.0 release. |
I am not clear on what your suggestion is right now. In any case, as you mention, And yes the use case was receiving a payload for validation, before sending it to a permanent store. Sometime you have fields which should be there for reads, but should not be writable. From the perspective of a system like that, |
i have no clear suggestion. ;-) here are two: a) clarifying the documentation. (also noting that it makes only sense if unknown fields are allowed.) b) turn a |
upgrading the docs should be fine I think. |
i think the
readonly
-rule isn't named intuitively. it could mean a lot and my guess is it was named for a certain use-case (propably validating before writing something). but it doesn't explain itself immediately and unambiguously. i had to read the code to fully get its purpose which turned out more trivial and explanatory to me than the docs.i propose to rename it to
is_exluded
.excluded
may be semantically enough, but it would be just one keystroke away fromexcludes
. another proposal isblacklisted
or to stick with an already used term:allowed
.the transition should be implemented like from
key-
tovalueschema
.a usage-example should be added to the documentation.
or is this an artifact from the time before
allow_unknown
was available?The text was updated successfully, but these errors were encountered: