Validate SQLModel on all Non-Database Sourced Data by ClayGendron · Pull Request #1823 · fastapi/sqlmodel
As noted by other issues and pull requests, when setting table=True in a SQLModel, Pydantic validation does not run, and this breaks the contract that "a SQLModel model is also a Pydantic model". This PR builds on prior ones and also hopes to address concerns with changing the intentional validation bypass for table models.
First, for those new to this issue, here is an example of how SQLModels behave differently when they are a table:
from pydantic import BaseModel, ValidationError from sqlmodel import SQLModel, Field class HeroBase(BaseModel): id: int | None = Field(default=None, primary_key=True) name: str age: int class HeroSQLBase(SQLModel): id: int | None = Field(default=None, primary_key=True) name: str age: int class HeroSQLTable(SQLModel, table=True): id: int | None = Field(default=None, primary_key=True) name: str age: int try: HeroBase(name="Deadpond", age="not an int") print("HeroBase: created with invalid data!") except ValidationError: print("HeroBase: ValidationError raised") try: HeroSQLBase(name="Deadpond", age="not an int") print("HeroSQLBase: created with invalid data!") except ValidationError: print("HeroSQLBase: ValidationError raised") try: HeroSQLTable(name="Deadpond", age="not an int") print("HeroSQLTable: created with invalid data!") except ValidationError: print("HeroSQLTable: ValidationError raised")
HeroBase: ValidationError raised
HeroSQLBase: ValidationError raised
HeroSQLTable: created with invalid data!
The same is true for @field_validator and @model_validator. Both will be silently ignored when table=True.
Use Case
I am building a library that includes a base SQLModel class (without table=True) that has validators to normalize and populate data. Downstream developers using my library would then create their own table=True class that inherits from the base:
# ---- library code ---- import hashlib import posixpath import uuid from pydantic import field_validator, model_validator from sqlmodel import SQLModel, Field class DocumentBase(SQLModel): id: str = Field( default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True ) path: str content: str content_hash: str = "" @field_validator("path") @classmethod def normalize_path(cls, v: str) -> str: if not v.startswith("/"): v = "/" + v return posixpath.normpath(v) @model_validator(mode="after") def compute_content_hash(self) -> "DocumentBase": self.content_hash = hashlib.sha256(self.content.encode()).hexdigest() return self # ---- downstream developer code ---- class Document(DocumentBase, table=True): project_field: str | None = None
The base class works correctly on its own, but it can't hold the downstream project_field:
>>> Document(path="not_normalized/../path", content="hello", project_field="important info!") DocumentBase( path='/path', # normalized content='hello', content_hash='2cf24db...', # computed # project_field missing! )
But when a downstream developer inherits with table=True, both validators are silently skipped:
>>> Document(path="not_normalized/../path", content="hello", project_field="important info!") Document( path='not_normalized/../path', # not normalized! content='hello', content_hash='', # not computed! project_field='important info!', )
My library must rely on validation from the custom defined inherited class, but it will not work out of the box. My issue could be resolved with the solution described in the multiple models doc, but that approach would mean I would be asking developers to create twice as many classes, one for validation and one for table mapping. Using SQLModel was chosen for this project as it promised to provide a unified model between Pydantic and SQLAlchemy, which in my case, means any initialized model derived from DocumentBase is valid, both in python and in the database.
The Change
The change is in sqlmodel_init() in _compat.py. Previously, table models called sqlmodel_table_construct() which skips validation entirely. Now, all models go through validate_python(), and table models do a post-validation step to re-trigger SQLAlchemy instrumentation via setattr:
def sqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) -> None: old_dict = self.__dict__.copy() self.__pydantic_validator__.validate_python( data, self_instance=self, ) if not is_table_model_class(self.__class__): object.__setattr__( self, "__dict__", {**old_dict, **self.__dict__}, ) else: fields_set = self.__pydantic_fields_set__.copy() for key, value in {**old_dict, **self.__dict__}.items(): setattr(self, key, value) object.__setattr__(self, "__pydantic_fields_set__", fields_set) for key in self.__sqlmodel_relationships__: value = data.get(key, Undefined) if value is not Undefined: setattr(self, key, value)
This mirrors the existing pattern used by sqlmodel_validate() (the model_validate() path) which already validates table models successfully.
Addressing Prior Concerns
"SQLAlchemy needs to assign values after instantiation" (#52)
The concern raised in #52 was that relationships need to be assignable after construction, so validation can't run on __init__.
Relationships are not part of model_fields — they live in __sqlmodel_relationships__ and are handled separately, outside of Pydantic validation. validate_python() never sees or validates relationship attributes. Both sides of a bidirectional relationship can be created independently, exactly as before:
from sqlmodel import SQLModel, Field, Relationship, Session, create_engine class Team(SQLModel, table=True): id: int | None = Field(default=None, primary_key=True) name: str heroes: list["Hero"] = Relationship(back_populates="team") class Hero(SQLModel, table=True): id: int | None = Field(default=None, primary_key=True) name: str team_id: int | None = Field(default=None, foreign_key="team.id") team: Team | None = Relationship(back_populates="heroes") # Create each side independently — no relationship passed team = Team(name="Preventers") hero = Hero(name="Deadpond") # Assign relationship after construction hero.team = team engine = create_engine("sqlite:///:memory:") SQLModel.metadata.create_all(engine) with Session(engine) as session: session.add(hero) session.commit() session.refresh(hero) print(f"{hero.name}'s team: {hero.team.name}")
Deadpond's team: Preventers
Performance on ORM Reads
Validation does not run when loading from the database. SQLAlchemy does not call __init__ when hydrating instances from query results (SQLAlchemy docs: Constructors and Object Initialization). This is unchanged, as it is safe to assume that data loaded from the database is valid.
To verify, here is a test that writes invalid data directly to the database and confirms it loads without triggering validation:
from pydantic import field_validator from sqlmodel import SQLModel, Field, Session, create_engine, select class Hero(SQLModel, table=True): id: int | None = Field(default=None, primary_key=True) name: str @field_validator("name") @classmethod def name_must_be_short(cls, v: str) -> str: if len(v) > 5: raise ValueError("too long") return v engine = create_engine("sqlite:///:memory:") SQLModel.metadata.create_all(engine) # Insert valid data through the model with Session(engine) as session: session.add(Hero(name="short")) session.commit() # Write invalid data directly to the database, bypassing the model with engine.connect() as conn: conn.execute( Hero.__table__.update() .where(Hero.__table__.c.id == 1) .values(name="this is way too long") ) conn.commit() # Load from database — no validation runs, invalid data loads fine with Session(engine) as session: loaded = session.exec(select(Hero)).first() print(f"Loaded from DB: {loaded.name!r}")
Loaded from DB: 'this is way too long'
Breaking Change
This could represent a behavior change for code that previously constructed table=True models with invalid data.
Related Issues and PRs
- #52 — SQLModel doesn't raise ValidationError
- #453 — Why does a SQLModel class with
table=Truenot validate data? - #134 — Pydantic Validators does not raise ValueError if conditions are not met
- #1041 — Ensure that type checks are executed when setting
table=True - #227 — Class Initialisation Validation Kwarg
Thank you for reviewing!