Bug Fixes

• Migration Serialization: Fixed an infinite recursion issue when serializing union types (e.g., list[Model] | None) in Django migrations on Python 3.11+. The fix wraps union arguments in a container to prevent Django’s IterableSerializer from recursing infinitely, ensuring migrations for complex schema fields are generated correctly.

Improvements

• Type Hints: Relaxed the type annotations for SchemaField to better support nullable schemas (e.g., SchemaField(schema=MyModel | None, null=True)). This improves static analysis compatibility when defining nullable fields and their default values.

Full Changelog: v0.5.1...v0.5.2

Added

• Declare support for TypedDict protocols as valid schemas in SchemaField.

Fixed

• Migration Serialization: Fixed serialization of Pydantic v2 constrained types (e.g., conint, constr) and Annotated types using annotated_types or StringConstraints in Django migrations.
• Migration Imports: RepresentationSerializer now correctly returns required imports.
• Nested Dataclasses: Fixed an issue where dataclass instances nested within generic containers (like list or dict) were not correctly wrapped for serialization.

What's Changed

• Fix migration serialization for Pydantic constraints and dataclasses by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/95

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.5.0...v0.5.1

Version 0.5.0 Release Notes

The core adaptation logic is moved into a SchemaAdapter layer that handles both Pydantic v1 and v2 through the same interface.

Key Improvements

• Cleaner Internal Architecture: By moving logic into SchemaAdapter, we’ve eliminated a lot of “if Pydantic v2 do this, else do that” code. This makes the field behavior identical regardless of which Pydantic version you are running.
• Stricter Pydantic v1 Isolation: For those still using Pydantic v1 models, they are now more effectively isolated within the .v1 subpackage. If you are running Pydantic v2 but still need to use legacy Pydantic v1 models, you can now do so explicitly by importing the field from the .v1 subpackage:

from django_pydantic_field.v1 import SchemaField as SchemaFieldV1

• Modernized Development Tooling: The project has switched to uv for dependency management and building. This won’t affect library users, but it makes contributing easier.

Breaking Changes

• Lazy Schema Resolution for Pydantic v1: To match the behavior of Pydantic v2 fields, v1 fields now resolve their schemas lazily. Previously, v1 schemas were resolved during Django Model class initialization. Now, resolution is deferred until the field is accessed. This allows for easier handling of forward references but may change the timing of when field errors are raised.
• CoreAPI Support Removed: Following Django REST Framework, we have dropped support for CoreAPI. If you need schema generation, please use the OpenAPI-based AutoSchema provided in django_pydantic_field.rest_framework.
• New Source Layout: The project now follows the standard src/ layout. This shouldn’t affect standard installations, but if you were importing from internal file paths or using a non-standard setup, you may need to adjust your configuration.

What's Changed

• chore: switch to uv by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/89
• Unify field logic using SchemaAdapter for Pydantic v1 and v2 by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/90
• Refactor compatibility layer and improve Pydantic v1/v2 isolation by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/91
• Refactor SchemaField for better Pydantic V1/V2 support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/92
• Update README.md by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/93
• Upgrade dev dependencies and fix test suite for Pydantic V2/Pytest 9 by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/94

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.4.1...v0.5.0

(backport of 0.5.1 fix)

Pydantic v2 types like conint and StringConstraints use internal objects (e.g., annotated_types.Gt) that Django cannot serialize by default. By ensuring GenericContainer wraps these dataclass-like instances and fixing the RepresentationSerializer to return necessary imports, these types can now be used in Django migrations.

Addresses https://github.com/surenkov/django-pydantic-field/issues/72, but only for Pydantic v2. Pydantic v1 requires a different approach as it generates the ad-hoc constrained types, and in light of https://github.com/surenkov/django-pydantic-field/issues/35 and https://github.com/surenkov/django-pydantic-field/issues/71, not worth an effort.

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.4.1...v0.4.2

What's Changed

• Add support for Django 6.0 by @RealOrangeOne in https://github.com/surenkov/django-pydantic-field/pull/88

New Contributors

• @RealOrangeOne made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/88

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.4.0...v0.4.1

What's Changed

• Fixes for Python 3.14. by @noamkush in https://github.com/surenkov/django-pydantic-field/pull/85
• Dropped support for Python 3.8 and 3.9 by @noamkush in https://github.com/surenkov/django-pydantic-field/pull/85

New Contributors

• @noamkush made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/85

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.13...v0.4.0

(backport of 0.5.1 fix)

Pydantic v2 types like conint and StringConstraints use internal objects (e.g., annotated_types.Gt) that Django cannot serialize by default. By ensuring GenericContainer wraps these dataclass-like instances and fixing the RepresentationSerializer to return necessary imports, these types can now be used in Django migrations.

Addresses https://github.com/surenkov/django-pydantic-field/issues/72, but only for Pydantic v2. Pydantic v1 requires a different approach as it generates the ad-hoc constrained types, and in light of https://github.com/surenkov/django-pydantic-field/issues/35 and https://github.com/surenkov/django-pydantic-field/issues/71, not worth an effort.

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.13...v0.3.14

What's Changed

• feat: fallback on json parsing in case of error by @quertenmont in #83

New Contributors

• @quertenmont made their first contribution in #83

Full Changelog: v0.3.12...v0.3.13

What's Changed

• Drop Python 3.7, declare 3.13 support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/76
• Use plain exception strings when throwing django.core.exceptions.ValidationError by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/79
• Type adaptation in from_db_value by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/78

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.11...v0.3.12

What's Changed

• fix ValidationError on empty form rendering by @amyasnikov in https://github.com/surenkov/django-pydantic-field/pull/75

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.10...v0.3.11

What's Changed

• Propagate allow_null parameter to base DRF Field by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/70

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.9...v0.3.10

What's Changed

• Bypass field validation on model instantiation if it does not contain a default= argument by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/63

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.8...v0.3.9

What's Changed

• Add django-jsonform widget incorporation for v2 fields by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/59

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.7...v0.3.8

In 0.3.5, I introduced an incompatibility with Pydantic v1: particularly, importing pydantic_core unconditionally in compatibility layer :eyes:. Thank you @Abdullah0297445 for the bringing attention to this!

Both 0.3.5 and 0.3.6 were yanked from PyPI, I highly encourage to upgrade your pinned versions if you're the lucky one who has experienced this issue.

What's Changed

• Removed a dangling import which is causing the install to fail in v0.3.5 and v0.3.6 by @Abdullah0297445 in https://github.com/surenkov/django-pydantic-field/pull/60

New Contributors

• @Abdullah0297445 made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/60

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.6...v0.3.7

What's Changed

• Use mode=json for get_prep_value during field value serialization by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/57

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.5...v0.3.6

What's Changed

• Setup pre-commit by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/53
• Support typing.Annotated annotations by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/52

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.4...v0.3.5

What's Changed

• Prepare a SchemaField's default value to work with RootModel schemas by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/51

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.3...v0.3.4

Make sure all expected primitives are exposed during dynamic module resolution in compatibility layer.

Allow (deprecated) django_pydantic_field.rest_framework.AutoSchema import with Pydantic 2.

What's Changed

• Ensure import resolution for compatibility layer by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/48

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.2...v0.3.3

What's Changed

• forms.SchemaField.to_python(): check if value already has a target type by @alexey-sveshnikov in https://github.com/surenkov/django-pydantic-field/pull/45

New Contributors

• @alexey-sveshnikov made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/45

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.1...v0.3.2

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.1...v0.3.2b1

What's Changed

• Add expressions handling for get_prep_value in v1 by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/47

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.0...v0.3.1

This release centers on the incorporation of v2 primitives. In the earlier version, Pydantic v1, support was achieved through a series of workarounds involving the manipulation of passed (or annotated) schemas. These schemas were wrapped into an intermediary RootModel to support both Pydantic models and most of the arbitrary annotations.

With v2, pydantic now ships a new primitive -- TypeAdapter -- which is well designed for this particular machinery.

Compatibility layer

To support both Pydantic v1 and v2, which might be useful during migration step, I added an indirection level during the import step. 0.3.0 contains implementations for both versions, with changes in v1 only required to make this compatibility layer to operate, with all behaviour remaining as in 0.2.13.

Lazy schema evaluation

In 0.2.* versions, exact schema resolution had been done in three stages:

1. First, the field tried to resolve the passed schema during field descriptor creation.
2. If it's failed, the next attempt had been performed during Django model class preparation, particularly in contribute_to_class method.
3. If even step 2 had failed (because of forward references might be still unresolvable at this stage), then the schema evaluation had to be postponed until the first attempt to access the field on model instance (either instance creation, field assignment or so).

In this update, I decided that evaluation logic should be as simple as possible, thus keeping only stage 3, and removing all the dirty logic that supported the machinery around 1 and 2 stages. To mitigate possible schema evaluation errors, which may appear only in runtime, the field now performs a few checks that are being performed by Django during app development lifecycle:

• manage.py check
• manage.py runserver
• manage.py makemigrations
• manage.py migrate
• and so on...

This check is relied on the same mechanics that you might see in plain JSONField, complaining on passing mutable structures itself, instead of callables (Django's field.E010 warning).

Additional integrity checks

Along with the schema evaluation check, the field now performes a few others, to make sure of its integrity:

• pydantic.E001 (a check from the section above). The schema cannot be resolved. It is most likely a programmatic error -- forward references cannot be resolved in the Django model's execution context.
• pydantic.E002. The field's default= value cannot be serialized by the specified schema. This may lead to runtime errors during model .save() or .objects.create(...) methods.
• pydantic.E003. If the field contains include= or exclude= export arguments, there could be a situation that value, written in the database, could not be restored back to python from its serialized form. This check tries to pass the specified default value (or the one that could be inferred directly from the schema, if default= is missing), through the whole transformation cycle, yielding a warning if the value could not be transformed back to python.

Additionally, JSONField's field.E010 warning is suppressed, as it is meaningless due to the nature of field transformations -- we're always getting a new value, not reusing the one passed to default= argument.

What's Changed

• Pydantic 2 support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/34
• Django serialization support by @amyasnikov in https://github.com/surenkov/django-pydantic-field/pull/41

New Contributors

• @amyasnikov made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/41

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.14...v0.3.0

What's Changed

• Django serialization support by @amyasnikov in https://github.com/surenkov/django-pydantic-field/pull/41

New Contributors

• @amyasnikov made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/41

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.0b1...v0.3.0b2

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.0a5...v0.3.0b1

What's Changed

• Add py.typed marker by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/40
• OpenAPI schema generation for parsers and renderers by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/34

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.0a4...v0.3.0a5

What's Changed

• Update README.md in https://github.com/surenkov/django-pydantic-field/pull/38;
• CoreAPI schema generator support;
• [WIP] Initial OpenAPI schema generator support (not finished yet).

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.0a3...v0.3.0a4

What's Changed

• Declare Django 5.0 support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/37

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.0a2...v0.3.0a3

Previous pre-release contained a broken package. Here's the new one (:

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.3.0a1...v0.3.0a2

Pydantic v2 initial support

Important note: 0.3.0a1 contained a broken package. Please take a look on 0.3.0a2 if you like to test it in the wild (:

This release is specifically focused on adding v2 primitives. Pydantic v1 was supported by a trickery around passed (or annotated) schema, wrapping it into intermediary RootModel to support both pydantic models and most of arbitrary annotations.

With v2, pydantic now contains the primitive -- TypeAdapter -- which is well designed for this particular machinery.

There's one remaining primitive is to be migrated prior final 0.3.0 -- OpenAPI AutoSchema generator, but since this library is already not super-sticky to the OpenAPI standard, I decided that alpha release could be rolled out without it.

Compatibility layer

To support both Pydantic v1 and v2, which might be useful during migration step, I added an indirection level during the import step. 0.3.0 contains implementations for both versions, with changes in v1 only required to make this compatibility layer to operate, with all behaviour remaining as in 0.2.11.

Lazy schema evaluation

In 0.2.* versions, exact schema resolution had been done in three stages:

1. First, the field tried to resolve the passed schema during field descriptor creation.
2. If it's failed, the next attempt had been performed during Django model class preparation, particularly in contribute_to_class method.
3. If even step 2 had failed (because of forward references might be still unresolvable at this stage), then the schema evaluation had to be postponed until the first attempt to access the field on model instance (either instance creation, field assignment or so).

In this update, I decided that evaluation logic should be as simple as possible, thus keeping only stage 3, and removing all the dirty logic that supported the machinery around 1 and 2 stages. To mitigate possible schema evaluation errors, which may appear only in runtime, the field now performs a few checks that are being performed by Django during app development lifecycle:

• manage.py check
• manage.py runserver
• manage.py makemigrations
• manage.py migrate
• and so on...

This check is relied on the same mechanics that you might see in plain JSONField, complaining on passing mutable structures itself, instead of callables (Django's field.E010 warning).

Additional integrity checks

Along with the schema evaluation check, the field now performes a few others, to make sure of its integrity:

• pydantic.E001 (a check from the section above). The schema cannot be resolved. It is most likely a programmatic error -- forward references cannot be resolved in the Django model's execution context.
• pydantic.E002. The field's default= value cannot be serialized by the specified schema. This may lead to runtime errors during model .save() or .objects.create(...) methods.
• pydantic.E003. If the field contains include= or exclude= export arguments, there could be a situation that value, written in the database, could not be restored back to python from its serialized form. This check tries to pass the specified default value (or the one that could be inferred directly from the schema, if default= is missing), through the whole transformation cycle, yielding a warning if the value could not be transformed back to python.

Additionally, JSONField's field.E010 warning is suppressed, as it is meaningless due to the nature of field transformations -- we're always getting a new value, not reusing the one passed to default= argument.

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.11...v0.3.0a1

What's Changed

• Backport django.core.serializers support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/42

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.13...v0.2.14

What's Changed

• Add py.typed marker by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/40

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.12...v0.2.13

What's Changed

• Declare Django 5.0 support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/37

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.11...v0.2.12

What's Changed

• Preserve kwargs for json.dumps() by @fdemmer in https://github.com/surenkov/django-pydantic-field/pull/30
• Support nested generic containers in schemas by @geigerzaehler in https://github.com/surenkov/django-pydantic-field/pull/32
• Fix equality check in GenericContainer by @geigerzaehler in https://github.com/surenkov/django-pydantic-field/pull/33

New Contributors

• @fdemmer made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/30
• @geigerzaehler made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/32

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.10...v0.2.11

What's Changed

• Raise ValidationError on form invalid JSON payload by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/29

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.9...v0.2.10

What's Changed

• Ensure that attributes set during contribute_to_class are copied. by @TomTruck in https://github.com/surenkov/django-pydantic-field/pull/27

New Contributors

• @TomTruck made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/27

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.8...v0.2.9

What's Changed

• Add backward support for pydantic 1.9.* by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/26

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.7...v0.2.8

What's Changed

• Updates to deconstruct() in SchemaField to preserve values of include and exclude by @oomojola in https://github.com/surenkov/django-pydantic-field/pull/23

New Contributors

• @oomojola made their first contribution in https://github.com/surenkov/django-pydantic-field/pull/23

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.6...v0.2.7

What's Changed

• Bring back JSON field lookups to work with schema [Django 4.2] by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/22

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.5...v0.2.6

What's Changed

• Add a bit of integration tests for models, forms and serializers by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/17
• Properly override get_prep_value and get_db_prep_value methods for PydanticSchemaField by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/20

Important note:

This release fixes #19, thus Django < 4.2 users should avoid installing previous one, v0.2.4. I'm considering to delist 0.2.4 from PyPI to minimize the potential harm.

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.4...v0.2.5

What's Changed

• Add support for Django 4.2 by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/15

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.3...v0.2.4

What's Changed

• Migrate setup.cfg to the sole pyproject.toml by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/13
• Extract pydantic export kwargs from fields' __init__ before calling super().__init__ by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/14

Closed: https://github.com/surenkov/django-pydantic-field/issues/12

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.2...v0.2.3

What's Changed

• Test support for python 3.11 by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/11

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.1...v0.2.2

The package supports Django starting from 3.1.

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.2.0...v0.2.1

What's Changed

• Python 3.7 + Django 3.2 support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/10

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.1.13...v0.2.0

What's Changed

• Django Forms schema field by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/9

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.1.12...v0.1.13

Un additin to typed collections and pydantic types, the field now also supports typing.Union, its special forms like typing.Optional and (only for py 3.10+) X | Y union annotations syntax.

What's Changed

• Union types support by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/8

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.1.11...v0.1.12

Enforced null checks for SchemaField

In the example below, typing linters should enforce type compatibility:

class BuildingMeta(pydantic.BaseModel):
    type: Optional[BuildingTypes]

class Building(models.Model):
    opt_meta: BuildingMeta = SchemaField(default={"type": "frame"}, null=True)
    meta: Optional[BuildingMeta] = SchemaField(default={"type": "frame"})

Pyright will complain on both fields:

sample_app/models.py:5:32 - error: Expression of type "BuildingMeta | None" cannot be assigned to declared type "BuildingMeta"
sample_app/models.py:6:40 - error: Expression of type "ST@SchemaField" cannot be assigned to declared type "BuildingMeta | None"

Mypy has more broaden resolution for latter check, but still be able to recognise first one:

sample_app/models.py:5: error: Incompatible types in assignment (expression has type "Optional[BuildingMeta]", variable has type "BuildingMeta")

Fixing field annotations will resolve issues on both checkers:

class Building(models.Model):
    opt_meta: Optional[BuildingMeta] = SchemaField(default={"type": "frame"}, null=True)
    meta: BuildingMeta = SchemaField(default={"type": "frame"})

The check also enforces default=None to have null=True param.

Relaxed restrictions on default= argument

In addition to null enforcement, typing checks allow arbitrary values for default= argument, as long as they are acceptable for pydantic's BaseModel.parse_obj method. Callables are also accepted, mimicking Django's field semantics.

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.1.10...v0.1.11

Slightly improve inheritance chain, better typings for SchemaField factory function.

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.1.9...v0.1.10

What's Changed

• Attempt to defer ForwardRefs resolution by @surenkov in https://github.com/surenkov/django-pydantic-field/pull/5

Full Changelog: https://github.com/surenkov/django-pydantic-field/compare/v0.1.8...v0.1.9

Django model fields are required to throw django.core.exceptions.ValidationError during .to_python(value) call. Let's stick to that recommendation.

Convert the input value into the expected Python data type, raising django.core.exceptions.ValidationError if the data can't be converted.

I believe that initially introduced error_handler= param is basically doesn't make sense, as it breaks regular validation flow and could be even harmful, as by default it simply suppress errors and writes them in logging. (Re)raising validation errors would be more explicit alternative to that.

I feel it's an overhead to define a full Config class in some cases, like:

class Config:
    json_encoders = ...

field: t.List[Schema] = SchemaField(config=Config)

The convenient solution is to pass a dict config instead:

field: t.List[Schema] = SchemaField(config={"json_encoders": ...})

Well, it is now possible to do so.

I'm considering current behavior with forward references resolution as expected. I.e. field schemas should be always defined before field declaration, otherwise it's not possible to bind a schema to the field during model initialzation. Note though, that annotation should still be declared as string/typing.ForwardRef, as long as prior constraint is satisfied. Main change: now such behavior is explicitly stated with tests.

I tried to defer schema initialzation at a field descriptor level, but this approach did not succeeded with current migrations flow

Now, instead specifying explicit schema, one could write:

from django.db import Model
from django_pydantic_field import SchemaField

class MyModel(models.Model):
    field: list[int] = SchemaField()

The schema will be inferred at model freezing step. Note that it's not possible to specify unresolved forward references at the moment.

This is the first minor release of django-pydantic-field, with field-level type definitions:

class Foo(pydantic.BaseModel):
    bar: int

class MyModel(models.Model):
    meta: list[Foo] = SchemaField(schema=list[Foo])

In order to support this, I had to introduce a breaking changes in field api defintion: all Pydantic-prefixed classes should be used without this prefix, e.g:

PydanticSchemaField -> SchemaField
PydanticSchemaRenderer -> SchemaRenderer
...