Pydantic 2 support

[surenkov]

I mentioned in #16 that this update should be prepared as soon as Pydantic v2 would go to RC, but well... I'm way behind the release schedule.

This would be a massive update for the library -- all fields will be redesigned from scratch, with as few breaking changes as possible, though Pydantic's interfaces have changed dramatically, so some incompatibilities are inevitable.

V1 fate

I'm planning to maintain compatibility with v1, and the package will include subpackages for both pydantic v1 and v2, and a small compatibility layer to dynamically resolve the correct subpackage based on the installed pydantic version.

There are no further improvements planned for v1. For future releases, it's better to focus on v2, as it has more benefits to support, like better performance and a nicer and cleaner API. Though v1 is still supported, just in maintenance-only state -- any issues coming from it should be taken into consideration.

IMPORTANT: I'm planning to deprecate and remove v1 in 1.0, as it deserves its own major release -- at least it should outlive Pydantic V1 end-of-life date.

Postponed annotations

One of the major areas of improvement is the annotation resolution. Pydantic v2 already has a deferred resolution semantics, unlike v1 which had the .update_forward_refs() model method.
Previously, the SchemaField first tried to resolve forward refs during Django model class initialisation, with a fallback to the first field access if it didn't succeed.
With v2, the underlying pydantic adapter becomes lazy and always reveals its type on first access, and now all possible misconfiguration errors are evaluated during Django's check command/runserver step.

Roadmap

• Compatibility layer to distinguish between V1 and V2:
  • Type annotations for dynamic module resolution
  • All tests pass for V1
  • All tests pass for V2
• V2 Django ORM field implementation:
  • Internal type adapter tests
  • Functional tests pass
  • Integration tests pass
  • Migration tests pass
• V2 Django Forms field implementation:
  • Functional tests pass
  • Integration tests pass
• V2 DRF adapters:
  • SchemaField implementation
  • SchemaParser implementation
  • SchemaRenderer implementation
  • coreapi.AutoSchema implementation
  • openapi.AutoSchema implementation
  • Functional tests pass
  • Integration tests pass

[PSU3D0]

Thank you for your work on this. Do you have an ETA for when this will be merged?

[surenkov]

Thank you for your work on this. Do you have an ETA for when this will be merged?

Hi @PSU3D0, thanks for your interest.
I'm planning to put some effort on finishing with OpenAPI schema generator for DRF on the weekend, but other APIs are pretty stabilized, and are very unlikely to be changed, so if you don't really need this missing part, you can already play around with pre-releases.

I have published them on PyPI, will be glad if you can take a look at them.

[utapyngo]

OpenAPI schema generator for DRF

Don't you use drf-spectacular for this?
Will django-pydantic-field conflict with drf-spectacular?

[surenkov]

@utapyngo honestly saying, I haven't checked the compatibility with drf-spectacular, but may suppose that at least it should not break anything, and behave as a plain JSONField, which is not perfect though, and supporting it deserves another PR.

Here I meant native AutoSchema generators which come built-in with DRF. From what I know, DRF authors already recommend starting from drf-spectacular instead, but I consider having support of DRF schema generators is still something necessary for the package.

[mihow]

Incredible! nice work and thank you.