Fix json validation of complex types in strict models

[JacobHayes]

I'd like to use SQLModel with strict models exposed via FastAPI. However, there seem to be a few edge cases specifically with date, UUID, and similar "complex" types that aren't native json types where the "strict validate json" behavior is not used and instead SQLModel/FastAPI/Pydantic is expecting the exact type (eg: a date or UUID instance) which obviously fails when we're parsing from a json string. For example, this script:

from datetime import date

from pydantic import BaseModel, ConfigDict, TypeAdapter
from sqlmodel import SQLModel

class Pydantic(BaseModel):
    value: date

class PydanticStrict(Pydantic):
    model_config = ConfigDict(strict=True)

class SQL(SQLModel):
    value: date

class SQLStrict(SQL):
    model_config = ConfigDict(strict=True)

json = '{"value": "1970-01-02"}'
for model in [Pydantic, PydanticStrict, SQL, SQLStrict]:
    print(f"{model.__name__}.model_validate_json: {model.model_validate_json(json)}")
    print(f"TypeAdapter({model.__name__}).validate_json: {TypeAdapter(model).validate_json(json)}")
    print()

errors for the SQLStrict model on main calling model_validate_json and TypeAdapter.validate_json while all of the other models work as expected.

---

This PR implements SQLModel.model_validate_json by splitting sqlmodel_validate into a main helper with *_python and *_json variants that defer to the appropriate Pydantic method.

This fixes the direct .model_validate_json calls, but there still seem to be some separate issues with the TypeAdapter. I'm not sure yet what's wrong with TypeAdaptor around SQLModels (given it works fine with PydanticStrict above), but this seems to be the main blocker for fixing the usage in FastAPI so I've kept this PR as a draft for now while I figure that out - I'd appreciate any guidance!

[SonOfLilit]

Is it me or is this redefined later in this file?

[novag]

It is wrapped inside an if else block for pydantic v1 vs v2 at line 72.

[novag]

Hi @JacobHayes,

This PR has been inactive for some time. Are you still able to work on it? If not, please let us know so we can continue the development from this point.

@tiangolo What is your perspective on this? Maybe you have an idea regarding the TypeAdapter.

[JacobHayes]

I'm not quite sure what to look into next and external PRs don't seem to be too prioritized (no judgement there, I know it takes a lot of work 😃), so I personally won't spend much more time on this.

The PR should be open to edits by maintainers or I'm happy to close if you all prefer.

[github-actions]

This pull request has a merge conflict that needs to be resolved.