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.
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.
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...
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.
There's also a lot to love about Pydantic alone. For me, the best thing about Pydantic is that I get performant, strongly validated objects. When I create Python apps, I try to make sure functions receive and return Pydantic models. That way, if the function does not fail, I'm 100% sure about the data coming in and out. It also saves me from writing many if statements.
Those Pydantic objects can also be dynamically created without losing the data validation parts. By using it, I feel very "secure" about my types and objects, but keeping the simplicity of Python for my whole app.