✏️ Fix pydantic invalid when table=True(#1036)

[monchin]

I found that when table=True is set, pydantic becomes invalid for usage like hero = Hero(name="Deadpond", secret_name="Dive Wilson", age="test"). As the document says you get all of Pydantic's features, including automatic data validation, serialization, and documentation. You can use SQLModel in the same way you can use Pydantic., I think table=True makes pydantic invalid is a bug, so I tried to fix it.

I delete a test case because this case is incompatible with pydantic. I also add a test case to ensure my code works. For current code, my new test case would fail, but it would pass for my new code.

[iloveitaly]

why was raw_self necessary here?

[monchin]

why was raw_self necessary here?

self.__pydantic_validator__.validate_python(
                data,
                self_instance=raw_self,
            )

would update self, and something would go wrong on sqlmodel_table_construct for the changed self. Maybe that's the reason that the original code dosen't validate when table=True.

Actually, we need to get the pydantic-validated dict, and use this dict to update the original dict, and then construct tables by the updated-original dict.

Anyway, you can try self_instance=self, and some unittests would fail.

[iloveitaly]

Some related issues for this one:

• Some discussion on how to run validations in sqlmodel
• Seems like pydantic validations are intended to be supported in sqlmodel

However, I think this comment indicates that this is actually the desired behavior.

[monchin]

this is actually the desired behavior

I regard this action as a bug rather than a feature because sqlmodel announce that you get all of Pydantic's features, including automatic data validation, serialization, and documentation. You can use SQLModel in the same way you can use Pydantic. Models with no validation when table=True is definitely not the way we are using pydantic.

[muhammadyaseen]

Hi all, is there a plan to merge this? Currently facing the same issues discussed in #11 and #453 (and several other related issues) and none of the proposed workaround seem clean enough for my use case.

Thanks.

[monchin]

@tiangolo Would you please look at this PR snd see whether this solution is OK? It passes all tests.