* moving docs to mkdocs * transfering readme to md and more * fixing build * splitting usage.md * improving schema.md and index.md * fix make_history.rst * models intro * working on data conversation and required fields * more fixes to models.md * list all standard types supported * list of pydantic types * tweaks * update links in code * Apply suggestions from code review incorporate @dmontagu's suggestions. Co-Authored-By: dmontagu <35119617+dmontagu@users.noreply.github.com> * Apply suggestions from code review more missed suggestions. Co-Authored-By: dmontagu <35119617+dmontagu@users.noreply.github.com> * Apply suggestions from code review more corrects. * cleanup * Field order warning * fix and regenerate benchmarks * format examples better, cleanup * improve schema mapping table * correct highlighting file types in schema.md * add redirects in javascript * add logo
5.2 KiB
Pydantic allows auto creation of JSON Schemas from models:
{!./examples/schema1.py!}
(This script is complete, it should run "as is")
Outputs:
{!./examples/schema1.json!}
The generated schemas are compliant with the specifications: JSON Schema Core, JSON Schema Validation and OpenAPI.
BaseModel.schema will return a dict of the schema, while BaseModel.schema_json will return a JSON string
representation of that.
Sub-models used are added to the definitions JSON attribute and referenced, as per the spec.
All sub-models (and their sub-models) schemas are put directly in a top-level definitions JSON key for easy re-use
and reference.
"sub-models" with modifications (via the Field class) like a custom title, description or default value,
are recursively included instead of referenced.
The description for models is taken from the docstring of the class or the argument description to
the Field class.
Field customisation
Optionally the Field function can be used to provide extra information about the field and validations, arguments:
default(positional argument), since theFieldis replacing the field's default, its first argument is used to set the default, use ellipsis (...) to indicate the field is requiredalias- the public name of the fieldtitleif omittedfield_name.title()is useddescriptionif omitted and the annotation is a sub-model, the docstring of the sub-model will be usedconstthis field must take it's default value if it is presentgtfor numeric values (int,float,Decimal), adds a validation of "greater than" and an annotation ofexclusiveMinimumto the JSON Schemagefor numeric values, adds a validation of "greater than or equal" and an annotation ofminimumto the JSON Schemaltfor numeric values, adds a validation of "less than" and an annotation ofexclusiveMaximumto the JSON Schemalefor numeric values, adds a validation of "less than or equal" and an annotation ofmaximumto the JSON Schemamultiple_offor numeric values, adds a validation of "a multiple of" and an annotation ofmultipleOfto the JSON Schemamin_itemsfor list values, adds a corresponding validation and an annotation ofminItemsto the JSON Schemamax_itemsfor list values, adds a corresponding validation and an annotation ofmaxItemsto the JSON Schemamin_lengthfor string values, adds a corresponding validation and an annotation ofminLengthto the JSON Schemamax_lengthfor string values, adds a corresponding validation and an annotation ofmaxLengthto the JSON Schemaregexfor string values, adds a Regular Expression validation generated from the passed string and an annotation ofpatternto the JSON Schema**any other keyword arguments (eg.examples) will be added verbatim to the field's schema
Instead of using Field, the fields property of the Config class can be used
to set all the arguments above except default.
The schema is generated by default using aliases as keys, it can also be generated using model
property names not aliases with MainModel.schema/schema_json(by_alias=False).
JSON Schema Types
Types, custom field types, and constraints (as max_length) are mapped to the corresponding
JSON Schema Core spec format when there's
an equivalent available, next to JSON Schema Validation,
OpenAPI Data Types
(which are based on JSON Schema), or otherwise use the standard format JSON field to define Pydantic extensions
for more complex string sub-types.
The field schema mapping from Python / Pydantic to JSON Schema is done as follows:
{!./.tmp_schema_mappings.html!}
Top-level schema generation
You can also generate a top-level JSON Schema that only includes a list of models and all their related
submodules in its definitions:
{!./examples/schema2.py!}
(This script is complete, it should run "as is")
Outputs:
{!./examples/schema2.json!}
Schema customization
You can customize the generated $ref JSON location, the definitions will still be in the key definitions and
you can still get them from there, but the references will point to your defined prefix instead of the default.
This is useful if you need to extend or modify JSON Schema default definitions location, e.g. with OpenAPI:
{!./examples/schema3.py!}
(This script is complete, it should run "as is")
Outputs:
{!./examples/schema3.json!}
It's also possible to extend/override the generated JSON schema in a model.
To do it, use the Config sub-class attribute schema_extra.
For example, you could add examples to the JSON Schema:
{!./examples/schema4.py!}
(This script is complete, it should run "as is")
Outputs:
{!./examples/schema4.json!}