Pydantic v2 support

[surenkov]

Important note: 0.3.0a1 contained a broken package, and I yanked it from PyPI. Please take a look on 0.3.0a2 or a newer if you'd 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 in the package import.
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 was done in three stages:

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

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

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

This check relies on the same mechanics that you might see in plain JSONField, which complains about passing mutable structures instead of callables as default parameter (Django's field.E010 warning).

Additional integrity checks

The field now performs several checks to ensure its integrity, in addition to the schema evaluation check:

• pydantic.E001 (a check from the section above): The schema cannot be resolved. This is most likely a programmatic error, such as forward references that 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 invocation.
• pydantic.E003: If the field contains include or exclude export parameters, there could be a situation where the 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 because it is meaningless due to the nature of field transformations. We always get a new value, not reuse the one passed as the default parameter.

Full Changelog: v0.2.11...v0.3.0a2

---

This discussion was created from the release Pydantic v2 initial support.

[surenkov]

@mihow @jvacek hey guys, sorry for bothering you with mentions -- I've noticed you've been particularly interested in Pydantic v2 support.

I published a pre-release 0.3.0a2 to PyPI, with its initial implementation, and would greatly appreciate if you'll have a chance to check that out.

Thank you, any of your feedback are very welcome!

[mihow]

Sorry I missed your comment earlier @surenkov. I will be testing your new release in our project this week or next.

[surenkov]

Great! I'm preparing the v0.3.0 for PyPI, and unless any circumstances will appear, planning to push it the next week.