PEP 563, PEP 649 and the future of pydantic and FastAPI

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by travisjungroth on Thursday April 15, 2021 @08:39PM (#26827964)

Have you written it with an ORM backed app? I’m curious if you put the business logic on the Pydantic models and keep the ORM small, or put the logic on the ORM and treat Pydantic like a serializer. Personally, I’d rather work with Pydantic models than ORM.

[ Parent | on HN ]

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by polyrand on Friday April 16, 2021 @04:17AM (#26831066)

I don’t use ORMs. For bigger apps, I use asyncpg and map the results to Pydantic objects. I write raw SQL and keep Pydantic objects as the “source of truth” throughout my app.

[ Parent | on HN ]

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by sandGorgon on Friday April 16, 2021 @01:44AM (#26829980)

there's a way to autogenerate pydantic and ORM (sqlalchemy) models from the same python dataclasses.

here's a fully functional gist - https://gist.github.com/sandys/671b8b86ba913e6436d4cb22d04b1...

[ Parent | on HN ]

Re:PEP 563, PEP 649 and the future of pydantic and FastAPI by madkat on Friday April 16, 2021 @05:26AM (#26831585)

We use SQLAlchemy as the ORM layer, but it's very small and most of the work is done with the Pydantic models. It works quite nicely, despite that we loose change tracking, but SQLAlchemy got us covered with merging models.

[ Parent | on HN ]