Validate SQLModel on all Non-Database Sourced Data

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.

[ClayGendron]

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:

frompydanticimportBaseModel, ValidationErrorfromsqlmodelimportSQLModel, FieldclassHeroBase(BaseModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLBase(SQLModel):
id: int|None=Field(default=None, primary_key=True)
name: strage: intclassHeroSQLTable(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strage: inttry:
HeroBase(name="Deadpond", age="not an int")
print("HeroBase: created with invalid data!")
exceptValidationError:
print("HeroBase: ValidationError raised")
try:
HeroSQLBase(name="Deadpond", age="not an int")
print("HeroSQLBase: created with invalid data!")
exceptValidationError:
print("HeroSQLBase: ValidationError raised")
try:
HeroSQLTable(name="Deadpond", age="not an int")
print("HeroSQLTable: created with invalid data!")
exceptValidationError:
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 ----importhashlibimportposixpathimportuuidfrompydanticimportfield_validator, model_validatorfromsqlmodelimportSQLModel, FieldclassDocumentBase(SQLModel):
id: str=Field(
default_factory=lambda: str(uuid.uuid4()), max_length=256, primary_key=True
)
path: strcontent: strcontent_hash: str=""@field_validator("path")@classmethoddefnormalize_path(cls, v: str) ->str:
ifnotv.startswith("/"):
v="/"+vreturnposixpath.normpath(v)
@model_validator(mode="after")defcompute_content_hash(self) ->"DocumentBase":
self.content_hash=hashlib.sha256(self.content.encode()).hexdigest()
returnself# ---- downstream developer code ----classDocument(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', # normalizedcontent='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:

defsqlmodel_init(*, self: "SQLModel", data: dict[str, Any]) ->None:
old_dict=self.__dict__.copy()
self.__pydantic_validator__.validate_python(
data,
self_instance=self,
)
ifnotis_table_model_class(self.__class__):
object.__setattr__(
self,
"__dict__",
{**old_dict, **self.__dict__},
)
else:
fields_set=self.__pydantic_fields_set__.copy()
forkey, valuein {**old_dict, **self.__dict__}.items():
setattr(self, key, value)
object.__setattr__(self, "__pydantic_fields_set__", fields_set)
forkeyinself.__sqlmodel_relationships__:
value=data.get(key, Undefined)
ifvalueisnotUndefined:
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:

fromsqlmodelimportSQLModel, Field, Relationship, Session, create_engineclassTeam(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strheroes: list["Hero"] =Relationship(back_populates="team")
classHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: strteam_id: int|None=Field(default=None, foreign_key="team.id")
team: Team|None=Relationship(back_populates="heroes")
# Create each side independently — no relationship passedteam=Team(name="Preventers")
hero=Hero(name="Deadpond")
# Assign relationship after constructionhero.team=teamengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
withSession(engine) assession:
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:

frompydanticimportfield_validatorfromsqlmodelimportSQLModel, Field, Session, create_engine, selectclassHero(SQLModel, table=True):
id: int|None=Field(default=None, primary_key=True)
name: str@field_validator("name")@classmethoddefname_must_be_short(cls, v: str) ->str:
iflen(v) >5:
raiseValueError("too long")
returnvengine=create_engine("sqlite:///:memory:")
SQLModel.metadata.create_all(engine)
# Insert valid data through the modelwithSession(engine) assession:
session.add(Hero(name="short"))
session.commit()
# Write invalid data directly to the database, bypassing the modelwithengine.connect() asconn:
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 finewithSession(engine) assession:
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=True not 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!

[mahdirajaee]

This is a significant behavioral change — table models now run Pydantic validation on __init__ instead of bypassing it via sqlmodel_table_construct. The key insight is that validate_python(data, self_instance=self) is called unconditionally for both table and non-table models now, which means field validators, model validators, and type coercion all fire during construction. The test suite additions are excellent and cover the critical scenarios: field_validator, model_validator (both before/after modes), BeforeValidator via Annotated, and crucially test_validation_does_not_run_on_orm_load which verifies that loading from the database still bypasses validation (important for not breaking existing data that might not pass newer validators).

The removal of sqlmodel_table_construct is the right call since it was essentially a copy of Pydantic's model_construct() that skipped validation — which was the original bug. One thing to watch: this is a breaking change for users who relied on being able to instantiate table models with missing required fields (the test_not_allow_instantiation_without_arguments test makes this explicit). The old test test_allow_instantiation_without_arguments previously passed with Item() where name: str had no default — that will now raise ValidationError. Projects doing item = Item(); item.name = "..." will need to migrate to Item(name="...").

The sqlmodel_init branching for table vs non-table models post-validation is sensible: non-table models merge dicts directly, while table models use setattr to trigger SQLAlchemy instrumentation and manually restore __pydantic_fields_set__. Worth confirming that the fields_set save/restore around the setattr loop doesn't cause issues if a setattr triggers a SQLAlchemy event that modifies __pydantic_fields_set__ internally, though that seems unlikely in practice.

[Graeme22]

This is great work and desperately needed! I hope @tiangolo will consider these changes. Might have to bump the middle version number, though the breakage this will cause will mostly be "good" in that it will catch incorrect code that was silently passing before.

In my projects I have a lot of code like:

classHeroValidate(SQLModel):
age: intclassHero(HeroValidate, table=True):
id: int=Field(...)
hero=HeroValidate(42)
hero_db=Hero(**hero.model_dump())
session.add(hero_db)

This is of course unwieldy, and it's quite clear many users have been bitten by this behavior at one point or another, so it should be a high priority to fix.

[clstaudt]

this breaks the contract that "a SQLModel model is also a Pydantic model".

Exactly. I was very surprised to realise that this is not actually the case. I hope this can be corrected soon.