Skip to content

Allow hybrid_property, hybrid_method and association_proxy on SQLModel classes#1990

Open
alvinttang wants to merge 1 commit into
fastapi:mainfrom
alvinttang:fix/ignore-sqlalchemy-descriptors-in-metaclass
Open

Allow hybrid_property, hybrid_method and association_proxy on SQLModel classes#1990
alvinttang wants to merge 1 commit into
fastapi:mainfrom
alvinttang:fix/ignore-sqlalchemy-descriptors-in-metaclass

Conversation

@alvinttang
Copy link
Copy Markdown

Summary

Defining a SQLModel class with a SQLAlchemy descriptor (hybrid_property, hybrid_method, or association_proxy) crashes at class-construction time with:

pydantic.errors.PydanticUserError: A non-annotated attribute was detected: `area = <sqlalchemy.ext.hybrid.hybrid_property object at 0x...>`. ... code='model-field-missing-annotation'

This is the long-standing #299 (20 reactions / 13 comments). The issue was mass-closed on 2026-05-18 alongside many other un-triaged bugs, but the bug is still present on main and community workarounds (subclass SQLModel and set model_config['ignored_types'] yourself) remain the only path. Reopening for review.

Root cause

Pydantic v2's inspect_namespace rejects every non-dunder, non-annotated attribute. hybrid_property / hybrid_method / association_proxy are SQLAlchemy descriptors users add without Python type annotations — that's the whole point of these descriptors. SQLModel never told Pydantic to treat them as ignored types via model_config['ignored_types'], so class construction crashes before SQLModel's metaclass even sees the column logic.

Fix

sqlmodel/main.py (+11 / -1):

  • Import AssociationProxy from sqlalchemy.ext.associationproxy and hybrid_method/hybrid_property from sqlalchemy.ext.hybrid.
  • Set SQLModel.model_config = SQLModelConfig(from_attributes=True, ignored_types=(hybrid_property, hybrid_method, AssociationProxy)).

Production diff is 10 net LOC.

This is intentionally disjoint and minimal: it stops the crash so users can define these descriptors on SQLModel classes. It does NOT implement DDL/expression generation for hybrid properties (a separate concern that PR #801 attempts in a much larger ~4400-line patch). Most users hitting #299 just want the descriptor to work at the Python level, which this PR enables.

Tests

tests/test_hybrid_property.py (new, 110 LOC, 4 tests):

  • test_table_model_allows_hybrid_property — table model + @hybrid_property ; instance returns the computed value.
  • test_table_model_allows_hybrid_method — table model + @hybrid_method.
  • test_table_model_allows_association_proxy — table model + association_proxy(...).
  • test_non_table_model_allows_hybrid_property — non-table model.

RED proof on main (4/4 fail):

pydantic.errors.PydanticUserError: A non-annotated attribute was detected: `area = <sqlalchemy.ext.hybrid.hybrid_property object ...>`

GREEN after patch: 4/4 pass; broader sweep pytest tests/ → 88 passed. ruff check / ruff format --check clean.

Risk notes

  • Behaviour change for non-table models that intentionally used hybrid_property as an unannotated raw attribute hoping Pydantic would treat it as a field: vanishingly unlikely, since hybrid_property is meaningless outside an ORM context.
  • No SQL-expression support added — leaves that scope to user code or to PR Support hybrid_property, column_property, declared_attr #801.
  • Test does not stress the SQL-expression code path of hybrids, only the Python-side descriptor / instance-attribute path that the issue actually reports.

Refs #299

… v2 crash

Defining a `sqlalchemy.ext.hybrid.hybrid_property` (or `hybrid_method`,
`association_proxy`) directly on a `SQLModel` class body raises
`pydantic.errors.PydanticUserError: A non-annotated attribute was detected`
under Pydantic v2 because those SQLAlchemy descriptors carry no Pydantic
annotation.

Add them to `SQLModel.model_config["ignored_types"]` so Pydantic skips them
during model construction, while SQLAlchemy continues to expose them as
descriptors at runtime.  Python-side hybrid evaluation now works on table
models; emitting them as SQL expressions/columns is intentionally still left
to user code (the proposed broader feature in PR fastapi#801).

Refs fastapi#299

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@alvinttang
Copy link
Copy Markdown
Author

Friendly bump: this PR has a required check-labels CI gate that needs a maintainer to apply the bug label (#299 is the underlying bug; tests are RED-on-main / GREEN-with-patch). Happy to address any review feedback in the meantime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants