✨ Ensure that type checks are executed when setting table=True

[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.

[spandan-sharma]

I think you should also do:

data = raw_self.model_dump()
self.__dict__ |= raw_self.__dict__

after validate_python is called on raw_self.

Otherwise you'll likely have broken model-validator behaviour, double default-factory calls etc. I explain all this here including why you need model_copy (or maybe even __dict__.copy() would do) - see Full Solution section at the bottom to skip the problem description etc.

[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.

[ohadc-orchid]

Hey, bumping this because we urgently need it as well :)

Thanks!

[aedan-chiari]

@ohadc-orchid

Fortunately, there seems to be an easy solution.

class Config:
        validate_assignment = True

from datetime import datetime

from pydantic import BaseModel
from sqlmodel import SQLModel, Field


class DatetimeModel(BaseModel):
    timestamp: datetime

class DatetimeSQLModel(SQLModel):
    id: str = Field("dummy", primary_key=True)
    timestamp: datetime

class DatetimeSQLTableModel(SQLModel, table=True):
    id: str = Field("dummy", primary_key=True)
    timestamp: datetime
    class Config:
        validate_assignment = True

t = '2024-11-13T12:30:12.584245Z'
m1 = DatetimeModel(timestamp=t)
m2 = DatetimeSQLModel(timestamp=t)
m3 = DatetimeSQLTableModel(timestamp=t)

print(type(m1.timestamp))
print(type(m2.timestamp))
print(type(m3.timestamp))

if __name__ == '__main__':
    pass

[paulomtts]

Bumping this. I get @tiangolo 's intention, but it seems that things are naturally leaning in another direction. If nothing is wrong with this implementation, then I think it's a huge step forward.

[furkansenol]

@ohadc-orchid

Fortunately, there seems to be an easy solution.

class Config:
        validate_assignment = True

from datetime import datetime

from pydantic import BaseModel
from sqlmodel import SQLModel, Field


class DatetimeModel(BaseModel):
    timestamp: datetime

class DatetimeSQLModel(SQLModel):
    id: str = Field("dummy", primary_key=True)
    timestamp: datetime

class DatetimeSQLTableModel(SQLModel, table=True):
    id: str = Field("dummy", primary_key=True)
    timestamp: datetime
    class Config:
        validate_assignment = True

t = '2024-11-13T12:30:12.584245Z'
m1 = DatetimeModel(timestamp=t)
m2 = DatetimeSQLModel(timestamp=t)
m3 = DatetimeSQLTableModel(timestamp=t)

print(type(m1.timestamp))
print(type(m2.timestamp))
print(type(m3.timestamp))

if __name__ == '__main__':
    pass

This works for type validations(as PR aims to fix) but it is not very helpful if you want to use field validators, please see the comment: #52 (comment)

Just wanted to point it out if someone ends up here looking for how to work with field or model validators like me.

[vimota]

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.

Agree with this interpretation, but at the same time the code seems to explicitly try to avoid that behaviour (https://github.com/fastapi/sqlmodel/blob/main/sqlmodel/_compat.py#L564). Would love some clarity from the FastAPI folks on the intention here. This was definitely the most surprising behaviour I noticed using SQLModel.

[svlandeg]

Hi all!

The current behaviour is clearly intentional, as stated in the docs and the code, and as further explained by Tiangolo here.

As such, I think it's unlikely that Tiangolo will want to change this behaviour. Nevertheless, I'll request his feedback internally.

Personally I think that if we choose to keep the current behaviour, we should consider adding more detailed documentation (and examples) about this functionality, as it's clearly unintuitive for many users.