Migrate to Pydantic V2 about ormar HOT 14 CLOSED

It's true that a lot of methods and logic was changed and was removed but when I started to check a lot of them are replaceable by something else, not sure yet if all of them but after all functionality wise the new version of pydantic covers most if not all of the previous use cases. There will be some breaking changes for sure as now config is a dict and not a inner class etc. The change scope is big so it will take time but I will try to port it to V2, will see if possible.

from ormar.

I've looked through ormar's code and pydantic's upgrade guide and many things used by ormar were removed without any alternative.

from ormar.

News?

from ormar.

Hi, Is there any progress ? Since FastApi has just released ther version 0.100.0 with pydantic v2

from ormar.

To save a little time for whoever else wants to start working on this:

See also #1151. Since Pydantic V2 retains the V1 API in a separate namespace pydantic.v1, one might hope for a quick&dirty fix in that PR’s branch dependabot/pip/pydantic-2.1.1 like this:

git grep -l 'from pydantic' | xargs sed -i -e 's/^from pydantic/from pydantic.v1/'
git grep -l '^import pydantic$' | xargs sed -i -e 's/^import pydantic$/import pydantic.v1 as pydantic/'

Which leaves only 19 errors in make test, all related to FastAPI support, however…

This, in turn, looks related to tiangolo/fastapi#9966: FastAPI, as of version 0.100.1, sets in fastapi._compat a flag PYDANTIC_V2, based on pydantic.version.VERSION[:2] == '2.'. It uses the flag in about 30 places throughout its code (tests excluded) to switch between V1 and V2 handling. Recalling from above: quick&dirty, could we toggle the flag and get this to run? Sadly, no.

This does not work, because FastAPI apparently sets up things at import time:

 from fastapi import FastAPI
+import pydantic.version as pydantic_version
+pydantic_version.VERSION = '1.999'

But neither does this, because FastAPI has import statements dependent on the Pydantic version, which fail if the flag is wrong:

+import pydantic.version as pydantic_version
+pydantic_version.VERSION = '1.999'
 from fastapi import FastAPI

So where to go from here?

• For ormar, enhancing the above idea with pydantic.v1 imports by a switch on the Pydantic version (i. e. import pydantic if V1 is installed, import pydantic.v1 as pydantic if V2 is installed) could be a first step. This is not really V2 support, but perhaps it could run with either V1 or V2 installed, as long as the entire application sticks to the V1 API.
• FastAPI might need to support V1 and V2 models in parallel with Pydantic V2 installed, per tiangolo/fastapi#9966. (This could, by the way, be helpful for users who would like to upgrade, but cannot migrate all their non-ormar models to V2 right away, and need to transition via pydantic.v1 for a while.) Which seems to require a lot of changes there, but at least the code for either case is already present.
  • A dirtier approach might be to tweak the PYDANTIC_V2 flag in FastAPI, but fix its import statements to load modules from pydantic.v1 if that’s available and PYDANTIC_V2 is False. I don’t imagine that this would pass any review, but maybe it would run.
• At this point, you should be able to run your ormar project with Pydantic V2, assuming you change your own code to import pydantic.v1 as needed.
• Will the ormar developer team will add and maintain parallel support for both Pydantic versions in the code, or make a hard switch from some release on? It would be nice to have compatible combinations of up-to-date Pydantic/FastAPI/ormar versions…

from ormar.

You can try version 0.20.0

from ormar.

@collerek You're awesome, thank you!

from ormar.

Very interested in this. Have tried looking at creating a PR myself with the upgrade, however it is definitely not a trivial task.

from ormar.

The problem is, that's, as you've already said, a quick and dirty fix and nothing for the long run.

from ormar.

It's true that a lot of methods and logic was changed and was removed but when I started to check a lot of them are replaceable by something else, not sure yet if all of them but after all functionality wise the new version of pydantic covers most if not all of the previous use cases. There will be some breaking changes for sure as now config is a dict and not a inner class etc. The change scope is big so it will take time but I will try to port it to V2, will see if possible.

Some great news! I really appreciate your response right here! Please keep us up to datea and many thanks again for this awesome library!

from ormar.

I like ormar very much, but because my project uses pydantic2, I have to choose other orm frameworks. I hope that the development team of ormar can support pydantic2 as soon as possible. I hope that ormar will get better and better

from ormar.

@hezhaozhao-git which orm has support for pydantic v2?

from ormar.

I haven't tried myself, but it seems that the most unique pydantic features can be bumped with this tool: https://github.com/pydantic/bump-pydantic

I'm not sure if they handle init and similar stuff not supported in pydantic v2, but I would try this.

from ormar.

Are there any news about using pydanticV2 in ormar? I am forced to use sqlachelmy with pydanticV2, but I would like to use something different

from ormar.