🐛 Fix alias support for Pydantic v2

[ravishan16]

Description

This PR fixes the Field(alias="...") functionality that was broken in Pydantic v2 while maintaining full backward compatibility with Pydantic v1.

Problem

In Pydantic v2, the alias parameter in SQLModel's Field function was not working correctly for validation and serialization. The issue was that Pydantic v2 requires explicit validation_alias and serialization_alias parameters, but SQLModel wasn't automatically propagating the alias value to these parameters.

Solution

Changes Made:

1. Enhanced Field function:

   • Added validation_alias and serialization_alias parameters
   • Implemented version-specific parameter handling

2. Automatic alias propagation:

   • Modified post_init_field_info in _compat.py to automatically set validation_alias and serialization_alias from alias when not explicitly provided (Pydantic v2 only) UPD YuriiMotov: updated it to just using alias value for validation_alias and serialization_alias if they are not specified directly

3. Backward compatibility:

   • Filter out v2-only parameters from FieldInfo in Pydantic v1
   • Raise clear RuntimeError when v2 features are used with v1
   • Conditional test execution based on Pydantic version

4. Comprehensive testing:

   • Added extensive test coverage for both Pydantic v1 and v2
   • Tests automatically skip v2-specific features when running with v1
   • Covers all alias scenarios including edge cases

Breaking Changes
None. This is purely a bug fix with backward compatibility maintained.

Closes
Fixes #1536

[YuriiMotov]

The idea looks good to me!

A couple of more things:

• I think it would be nice to use alias as a default value for DB column. It can then be overridden by sa_column=Column("column_name") - decided to handle it in separate PR later
• We should probably test how it works with alias generators specified in model's config (is it supported? - UPD: YES) (done)

PS: @svlandeg, sorry, I only noticed you self-assigned this PR when I was about to press "Submit review".. Hope you don't mind I submitted this review)

[YuriiMotov]

We should think whether we want to keep parameterizing tests with Pydantic models.
Initially I parametrized tests with both, Pydantic and SQLModel models to show the difference in behavior between SQLModel and Pydantic models.

If it's useful to keep this parametrization in repo? 🤔
Tests would be a bit simpler without it, but on the other hand this way we ensure it works the same as with Pydantic model

[ravishan16]

Personally, I think it’s useful to keep the parametrization for now, since it acts as a kind of integration test between the two libraries.

[YuriiMotov]

Pydantic's validation_alias type annotation is wider (validation_alias: str | AliasPath | AliasChoices | None), but I think it's fine if we only support str for now and extend it later

[ravishan16]

I don't have a strong preference on this.

[svlandeg]

Hope you don't mind I submitted this review

Of course not! I tentatively assign PRs when I want to review them in the near future, just to keep track of them, but sometimes other tasks come in between 🙈 Feel free to review whatever you want!

[ravishan16]

@YuriiMotov @svlandeg I’ve addressed all the comments from the review. Let me know if there’s anything else you’d like me to focus on.

[YuriiMotov]

I simplified code a bit - moved alias propagation logic to Field.__init__ so that it would be all in one place.
Also, got rid of deprecation warnings in test.

[YuriiMotov]

LGTM!

Implementation is not breaking. It also handles the workaround with

Field(schema_extra={"validation_alias": "field_alias"})

that people currently use.

The only use case it can break is if users use

Field(schema_extra={"validation_alias": "field_alias"})

and want to use this model with both, Pydantic V1 and V2.
It will now raise

RuntimeError("validation_alias is not supported in Pydantic v1")

for Pydantic V1.
But it's easily fixable - just remove validation_alias (now alias works with both versions, so that workaround is not needed).

To Sebastian:

Some tests are parameterized to be run with both, SQLModel and Pydantic models, to show that they behave the same way. If you don't like it, it's easy to remove it.

@ravishan16, thank you!