Working with Pydantic v1 while having v2 installed #9966

slafs · 2023-07-29T12:55:48Z

slafs
Jul 29, 2023

This is a continuation of a topic introduced in #9709 (comment) as requested by @Kludex. I've chosen the "Show and tell" category as the (lack of) template seems better for this discussion.

In the original thread I've asked if there's a way to work with pydantic v1 while having v2 installed:

Pydantic v2 ships the latest version of v1 for easier migration, so the pattern is to work with v1 via things like from pydantic.v1 import BaseModel etc. while having v2 installed.

Currently, this approach doesn't seem to work with FastAPI 0.100.0 and the following snippet:

from fastapi import FastAPI

from pydantic.v1 import BaseModel


class Model(BaseModel):
    foo: str = "foo"
    bar: int = 2


app = FastAPI()


@app.get("/")
def root(model: Model) -> Model:
    return model

produces the following error:

Traceback (most recent call last):
  File ".../fiddles/fastapi_pydantic_v1_on_v2.py", line 15, in <module>
    def root(model: Model) -> Model:
  File ".../lib/python3.10/site-packages/fastapi/routing.py", line 706, in decorator
    self.add_api_route(
  File ".../lib/python3.10/site-packages/fastapi/routing.py", line 645, in add_api_route
    route = route_class(
  File ".../lib/python3.10/site-packages/fastapi/routing.py", line 448, in __init__
    self.response_field = create_response_field(
  File ".../lib/python3.10/site-packages/fastapi/utils.py", line 101, in create_response_field
    raise fastapi.exceptions.FastAPIError(
fastapi.exceptions.FastAPIError: Invalid args for response field! Hint: check that <class '__main__.Model'> is a valid Pydantic field type. If you are using a return type annotation that is not a valid Pydantic field (e.g. Union[Response, dict, None]) you can disable generating the response model from the type annotation with the path operation decorator parameter response_model=None. Read more: https://fastapi.tiangolo.com/tutorial/response-model/

Switching from pydantic.v1 to just pydantic (v2) obviously works.

I'm seeing there's fastapi._compat module and PYDANTIC_V2 var, but I'm not sure if that's the right direction.

For reference, installed versions:

fastapi==0.100.0
pydantic==2.0.3
pydantic_core==2.3.0

Now... that being said, I'm not even sure if this would be helpful to anyone even if FastAPI did support it. My initial thought was that this would ease the migration, but the reality seems more complicated. E.g. models are used by other models and even Pydantic itself doesn't support mixing v1 and v2 together. So given that the cost of figuring out the plan for the gradual migration seems comparable with doing the whole migration at once (at least for us).

Maybe it would be useful if people commented on their intended use case and see if that's actually a feature that's needed/wanted.

chbndrhnns · 2023-08-03T14:41:41Z

chbndrhnns
Aug 3, 2023

Well, I expect v1 models to work out of the box based on the comment on https://fastapi.tiangolo.com/release-notes/?h=v1#01000:

This version of FastAPI still supports Pydantic v1. And although Pydantic v1 will be deprecated at some point, ti will still be supported for a while.

On my use case, I'd like to be able to migrate models one by one while my system is still running.

0 replies

estarfoo · 2023-08-04T17:42:58Z

estarfoo
Aug 4, 2023

I came across this issue in the context of collerek/ormar#1115. The behaviour in 0.100, with the PYDANTIC_V2 switch, excludes any upgrade path via pydantic.v1 imports, which seems to have been intended in Pydantic.

The logic around the various references to PYDANTIC_V2 in the code mostly seems to happen where there is a BaseModel instance nearby. Would it maybe suffice to check, in each place, whether (PYDANTIC_V2 and not type(obj) is V1_BaseModel), given import pydantic.v1.BaseModel as V1_BaseModel, before handling the model as V2-based?

(Would anyone need a fastapi.openapi.models.v1 in that case? Outside of fastapi._compat, that’s most of the places where the distinction is currently being made.)

0 replies

chbndrhnns · 2023-09-08T15:41:41Z

chbndrhnns
Sep 8, 2023

I gave it a try at #10223 to support v1 models in request and response body.

0 replies

HammadB · 2023-09-21T23:34:55Z

HammadB
Sep 21, 2023

I would really expect this to work, we are running into it here chroma-core/chroma#893 (comment)

0 replies

o-fedorov · 2023-09-29T08:06:54Z

o-fedorov
Sep 29, 2023

Hi. For a response model based on pydantic.v1.BaseModel we've run into a similar issue, but this time it is TypeError:

  File ".../lib/python3.10/site-packages/fastapi/_compat.py", line 125, in validate
    self._type_adapter.validate_python(value, from_attributes=True),
  File ".../lib/python3.10/site-packages/pydantic/type_adapter.py", line 283, in validate_python
    return self.validator.validate_python(__object, strict=strict, from_attributes=from_attributes, context=context)
TypeError: BaseModel.validate() takes 2 positional arguments but 3 were given

fastapi==0.103.2
pydantic==2.4.2
pydantic_core==2.10.1

4 replies

Kludex · 2023-10-01T06:56:38Z

Kludex
Oct 1, 2023
Collaborator

Let's follow it on #10360. No confirmation needed.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Working with Pydantic v1 while having v2 installed #9966

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 4 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Working with Pydantic v1 while having v2 installed #9966

Replies: 6 comments · 4 replies

Kludex Oct 1, 2023 Collaborator

Replies: 6 comments 4 replies

Kludex
Oct 1, 2023
Collaborator