-
-
Notifications
You must be signed in to change notification settings - Fork 51
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
Support for additionalProperties=False #106
Comments
Well - although you can set additional attributes to an instance, these attribute won't make it to the actual JSON. from jsonmodels.models import Base
from jsonmodels.fields import *
class Foo(Base):
age = IntField()
f = Foo()
f.bar = "hello"
f.age = 4
f.to_struct() The above code will yield You could make the code raise an exception if a new attribute is introduces, but this is not very "pythonic", and does not provide a real value IMO. Notice that you can add new fields to an existing class Foo(Base):
age = IntField()
Foo.to_json_schema()
Out[1]:
{'additionalProperties': False,
'properties': {'age': {'type': 'number'}},
'type': 'object'}
Foo.bar = StringField()
Foo.to_json_schema()
Out[2]:
{'additionalProperties': False,
'properties': {'age': {'type': 'number'}, 'bar': {'type': 'string'}},
'type': 'object'} |
Hey @smurfix, thanks for the feedback! Answering to your notice - well, the intention was different for that. Imagine case like this (pseudocode):
and with this you could easily use birth date even if it isn't given explicite by your data source without calculating it each time in many places in code. This approach allows for flexibility in extending models for your use cases. |
OK, fair enough. However, models should describe their data exhaustively. Thus it makes sense to forbid random elements. The easiest way to specify that is to not mention it in the class. Thus, in your example, if |
Hmm, |
For those getting here from google, who have models where it is emphatically impossible to describe their data exhaustively (i.e. for a set of user-defined parameters) I've sufficiently simulated
Since it's a Field instead of a model, it requires that all of your arbitrary properties be confined into their own scope rather than mingling with the rest of the validated fields. |
Even though the generated JSON schema contains "additionalProperties: False" for every structure, actually setting a property that's not in the model does not cause a validation error.
It should. in the meantime, emitting "additionalProperties: False" is wrong, strictly speaking.
The text was updated successfully, but these errors were encountered: