Skip to content

Latest commit

 

History

History
135 lines (98 loc) · 5.41 KB

model_config.md

File metadata and controls

135 lines (98 loc) · 5.41 KB
Raw

Behaviour of pydantic can be controlled via the Config class on a model.

Options:

title : the title for the generated JSON Schema

anystr_strip_whitespace : whether to strip leading and trailing whitespace for str & byte types (default: False)

min_anystr_length : the min length for str & byte types (default: 0)

max_anystr_length : the max length for str & byte types (default: 2 ** 16)

validate_all : whether to validate field defaults (default: False)

extra : whether to ignore, allow, or forbid extra attributes during model initialization. Accepts the string values of 'ignore', 'allow', or 'forbid', or values of the Extra enum (default: Extra.ignore). 'forbid' will cause validation to fail if extra attributes are included, 'ignore' will silently ignore any extra attributes, and 'allow' will assign the attributes to the model.

allow_mutation : whether or not models are faux-immutable, i.e. whether __setattr__ is allowed (default: True). False will make the model immutable and hashable i.e. a default __hash__ function is generated for you, but you can still overwrite it.

use_enum_values : whether to populate models with the value property of enums, rather than the raw enum. This may be useful if you want to serialise model.dict() later (default: False)

fields : a dict containing schema information for each field; this is equivalent to using the Field class (default: None)

validate_assignment : whether to perform validation on assignment to attributes (default: False)

allow_population_by_field_name : whether an aliased field may be populated by its name as given by the model attribute, as well as the alias (default: False)

!!! note The name of this configuration setting was changed in v1.0 from allow_population_by_alias to allow_population_by_field_name.

error_msg_templates : a dict used to override the default error message templates. Pass in a dictionary with keys matching the error messages you want to override (default: {})

arbitrary_types_allowed : whether to allow arbitrary user types for fields (they are validated simply by checking if the value is an instance of the type). If False, RuntimeError will be raised on model declaration (default: False). See an example in Field Types.

orm_mode : whether to allow usage of ORM mode

getter_dict : a custom class (which should inherit from GetterDict) to use when decomposing ORM classes for validation, for use with orm_mode

alias_generator : a callable that takes a field name and returns an alias for it

keep_untouched : a tuple of types (e.g. descriptors) for a model's default values that should not be changed during model creation and will not be included in the model schemas. Note: this means that attributes on the model with defaults of this type, not annotations of this type, will be left alone.

schema_extra : a dict used to extend/update the generated JSON Schema, or a callable to post-process it; see Schema customization

json_loads : a custom function for decoding JSON; see custom JSON (de)serialisation

json_dumps : a custom function for encoding JSON; see custom JSON (de)serialisation

json_encoders : a dict used to customise the way types are encoded to JSON; see JSON Serialisation

{!.tmp_examples/model_config_main.py!}

(This script is complete, it should run "as is")

Similarly, if using the @dataclass decorator:

{!.tmp_examples/model_config_dataclass.py!}

(This script is complete, it should run "as is")

Alias Generator

If data source field names do not match your code style (e. g. CamelCase fields), you can automatically generate aliases using alias_generator:

{!.tmp_examples/model_config_alias_generator.py!}

(This script is complete, it should run "as is")

Here camel case refers to "upper camel case" aka pascal case e.g. CamelCase. If you'd like instead to use lower camel case e.g. camelCase, it should be trivial to modify the to_camel function above.

Alias Precedence

!!! warning Alias priority logic changed in v1.4 to resolve buggy and unexpected behaviour in previous versions. In some circumstances this may represent a breaking change, see #1178 and the precedence order below for details.

In the case where a field's alias may be defined in multiple places, the selected value is determined as follows (in descending order of priority):

  1. Set via Field(..., alias=<alias>), directly on the model
  2. Defined in Config.fields, directly on the model
  3. Set via Field(..., alias=<alias>), on a parent model
  4. Defined in Config.fields, on a parent model
  5. Generated by alias_generator, regardless of whether it's on the model or a parent

!!! note This means an alias_generator defined on a child model does not take priority over an alias defined on a field in a parent model.

For example:

{!.tmp_examples/model_config_alias_precedence.py!}

(This script is complete, it should run "as is")