Full Pydantic 2.0 Support + Bug Fixes #691
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When upgrading to pydantic 2.0, we ran into many issues. It seemed like anything outside of a very simple implementation would not work.
We believed initially that we had to remove support for pydantic 1.0 to fix all of these. Now, we see it might be possible to still allow for compatibility across both versions but there are other breaking changes proposed so we just left it as we felt it would be best.
The main issues we initially faced were:
test_model_validate_uses_default_values
)model_fields_set
was not accurate which resulted in anything that relied onexclude_unset=True
to not workcontext
object that can be passed in when validating a model was being set toNone
KNNExpression
was expectingscore_field
to be aModelField
which was removed in 2.0 and would result in anAttributeError
if usedWe were also using pydantic in ways that weren't supported and there was a lot of implicit behavior that changed that was not covered in any documentation or the migration guide. That was the core of a lot these issues.
To fix 1, we added
field
to theredis-om
FieldInfo
object so we have access to the field name everywhere and we don't have to rely onalias
. (candidly, this also made some refactoring on our side much easier)To fix 2 and 3, we took inspiration from sqlmodel and allowed for explicitly setting when to "index" a model (similar to
table=True
insqlmodel
). This means that we only set the class attributes to anExpressionProxy
once, which fixed the default errors. This was happening because pydantic was reading theExpressionProxy
set on fields further up in the inheritance tree and thinking it was the default value. This is a breaking change but with how pydantic 2.0 works, we feel it makes the most sense. It also creates an easy way to preventredis-om
models that won't be queried from being indexed.For 4, we believe requiring pydantic 2.0 (also a breaking change) and using the new
field_validator
decorator to validatepk
fixed this issue.For 5, we upgraded the
KNNExpression
to allow for a little more flexibility and updated it to use theredis-om
FieldInfo
class with name.