Frozen field assignment raises ValidationError but mutates ORM state and persists on commit

[msmakb]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the documentation, with the integrated search.
• I already searched in Google "How to X" and didn't find any information.
• I already read and followed all the tutorials in the docs and didn't find an answer.

Example Code

fastapi> from pydantic import ValidationError
     ... from sqlmodel import Field, Session, SQLModel, create_engine
     ...
     ...
     ... class FrozenProbe(SQLModel, table=True):
     ...     id: int | None = Field(default=None, primary_key=True)
     ...     code: str = Field(schema_extra={"frozen": True})
     ...
fastapi> engine = create_engine("sqlite://")
     ... SQLModel.metadata.create_all(engine)
     ...
fastapi> with engine.begin() as connection:
     ...     connection.execute(
     ...         FrozenProbe.__table__.insert().values(id=1, code="original")
     ...     )
     ...
fastapi> with Session(engine) as session:
     ...     record = session.get(FrozenProbe, 1)
     ...     assert record is not None
     ...
     ...     try:
     ...         record.code = "changed"
     ...     except ValidationError:
     ...         print("Assignment rejected")
     ...
     ...     print(record.code)
     ...     session.commit()
     ...
Assignment rejected
changed
fastapi> with Session(engine) as session:
     ...     saved = session.get(FrozenProbe, 1)
     ...     assert saved is not None
     ...     print("Database value:", saved.code)
     ...
Database value: changed

Description

Assigning a new value to a frozen field on a database-loaded SQLModel raises ValidationError, but still changes the object's value and SQLAlchemy state.

I expect the rejected assignment to leave the original value unchanged.

Instead, after catching the error, the field contains the rejected value. Calling session.commit() persists that value, and loading the record in a new session confirms the change.

This concerns field-level freezing (Field(schema_extra={"frozen": True})) on a table=True model.

Operating System

macOS

Operating System Details

No response

Project Version

Python 3.15.0rc2 · SQLModel 0.0.48 · SQLAlchemy 2.1.5 · Pydantic 2.14.1.

Python Version

python 3.15

Additional Context

No response

[sueun-dev]

This comes from the order inside SQLModel.__setattr__. For table models it calls SQLAlchemy's set_attribute() first and only then hands off to Pydantic, which is where the frozen check raises: main.py L885-896 at 0.0.48. By the time you see the ValidationError, SQLAlchemy has already recorded the change and the object is in session.dirty. The same code is still on main.

I ran your example on SQLModel 0.0.48, SQLAlchemy 2.1.5, Pydantic 2.14.1 (Python 3.15.0rc3) and got the same result. Expiring just that attribute in the except block fixes it:

except ValidationError:
    session.expire(record, ["code"])

After that, record.code reloads as original, the commit leaves the row unchanged, and other edits on the object are kept. session.rollback() also restores it, but in my test it dropped another unflushed change on the same object too. Side note: FrozenProbe(code="new") also raises frozen_field in this setup. Open PR #1873 only changes the construct/validate paths for model-level frozen, not this assignment order.

[msmakb]

I know we can use a workaround, as you suggested, with session.expire(record, ["code"]), but this doesn't fix the underlying issue.

I've already investigated this and identified a potential execution-order issue involving both SQLAlchemy and SQLModel's setters. Looking at the source code, it appears that SQLAlchemy's setattr is executed before Pydantic's, triggering events and updates.

That's why I raised this discussion: to investigate whether this is a bug or unexpected behavior and find a way to fix the root cause directly in the source code rather than relying on workarounds.

[dfbustosus]

Yes — this is a bug in the contract sense, and your read of the execution order is correct. Here's the full mechanism, why the code is structured that way, and what a root fix would look like.

Exact mechanism (still on main):

# Set in SQLAlchemy, before Pydantic to trigger events and updates
if is_table_model_class(self.__class__) and is_instrumented(self, name):
    set_attribute(self, name, value)
# Set in Pydantic model to trigger possible validation changes...
if name not in self.__sqlmodel_relationships__:
    super().__setattr__(name, value)

1. set_attribute() writes self.__dict__["code"], fires the SQLAlchemy set event, and records attribute history — so the object lands in session.dirty.
2. Only then does super().__setattr__() reach pydantic's validator, which raises frozen_field.
3. The exception propagates, but nothing rolls back step 1 — SQLAlchemy has no idea a later validator rejected the write. session.commit() then flushes the recorded history, which is why a fresh session reads changed.

That's the contract violation: for frozen fields pydantic guarantees raise and leave the attribute unchanged; here the raise happens but the mutation survives. (There's precedent for this class of mismatch: #262 for allow_mutation=False.)

Why not just swap the two calls? The code comment ("Set in SQLAlchemy, before Pydantic to trigger events and updates") hints at the reason: pydantic's validate_assignment writes __dict__ directly. If it ran first, the value would land in the instance dict bypassing instrumentation — no set event, no attribute history — so commit() would silently stop seeing table-model edits. The order is deliberate; what's missing is the failure path.

A safe root fix is validate-or-restore:

if is_table_model_class(self.__class__) and is_instrumented(self, name):
    old = get_attribute(self, name)          # current value, lazy-load safe
    set_attribute(self, name, value)         # instrumented write, events fire
    try:
        super().__setattr__(name, value)     # pydantic validation
    except ValidationError:
        set_attribute(self, name, old)       # restore via instrumentation
        raise
    return

Because the restore also goes through set_attribute and the net old→old change leaves the attribute history clean, the object drops back out of the session's dirty set (pre-existing edits to other fields are untouched), so a later commit() persists nothing for this field. That fixes your repro at the source, without the session.expire() workaround and without changing event ordering on the success path.

I'd open this as an issue — your repro (rejected assignment + Database value: changed) is already the minimal case; the only maintainer decision needed is validate-then-set vs restore-on-error.