SQLModel fails to create DB constraints when using Annotated types after Pydantic 2.12.0

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623

[MarishLakshmanan]

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 SQLModel documentation, with the integrated search.
• I already searched in Google "How to X in SQLModel" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to SQLModel but to Pydantic.
• I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

• I commit to help with one of those options 👆

Example Code

Environment:
Pydantic==2.12.0Code:
frompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints(strip_whitespace=True, min_length=1)]
ClassTest(SQLModel):
id: NonEmptyString=Field(primary_key=True) # this was working fine on pydantic v2.11.9

Description

Description

After upgrading to Pydantic 2.12.0, SQLModel no longer creates database constraints (like primary keys, unqiue keys ) for fields defined using Annotated types.

Example:

fromtypingimportAnnotatedfromsqlmodelimportSQLModel, FieldfrompydanticimportStringConstraintsNonEmptyString=Annotated[str, StringConstraints()]
classTest(SQLModel, table=True):
id: NonEmptyString=Field(primary_key=True)

Expected Behavior

The table should be created with id as an varchar and primary key

Actual Behavior

it throws an error

sqlalchemy.exc.ArgumentError: Mapper Mapper[Test(test)] could not assemble any primary key columns for mapped table 'test'

Additional notes

In case you use an unique key constraint the table will be created, you will not get any error but the unique key constraint will not be created.

Operating System

Linux

Operating System Details

No response

SQLModel Version

0.0.26

Python Version

3.13.3

Additional Context

No response

[YuriiMotov]

Similar: #1596

[pstanisl]

Similar issues for:

Pydantic dicriminator:

 File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 658, in get_sqlalchemy_type
type_ = get_sa_type_from_field(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 229, in get_sa_type_from_field
return get_sa_type_from_type_annotation(type_)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\_compat.py", line 214, in get_sa_type_from_type_annotation
raise ValueError(
ValueError: Cannot have a (non-optional) union as a SQLAlchemy field
make: *** [Makefile:242: prestart] Error 1

And Python list

File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 565, in __new__
col = get_column_from_field(v)
^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 714, in get_column_from_field
sa_type = get_sqlalchemy_type(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\evkas\repo\backend-api\.venv\Lib\site-packages\sqlmodel\main.py", line 703, in get_sqlalchemy_type
raise ValueError(f"{type_} has no matching SQLAlchemy type")
ValueError: <class 'list'> has no matching

[vimota]

Added a fix in this PR: https://github.com/fastapi/sqlmodel/pull/1607/files

[vimota]

cc @YuriiMotov

[MarishLakshmanan]

Yeah, that fixes my issue. Thanks!!! @vimota

[nielsreijers]

I'm not sure if I should open a new issue for my problem or not, but it's very related to what's being discussed here.

This minimal example:

import sqlmodel
class Event(sqlmodel.SQLModel, table=True):
id: int = sqlmodel.Field(default=None, primary_key=True)
event_data: dict = sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
class StartEvent(Event, table=False):
pass

fails with ValueError: <class 'dict'> has no matching SQLAlchemy type because Pydantic replaces the SQLModel FieldInfo with it's own, thus losing the sa_type property.

I've manually applied the fixes in these PRs (including the one mentioned above), but none of them seem to fix the problem.
#1577
#1603
#1607

Are we doing something wrong here? The example here doesn't make much sense, but the original code was one of several experiments with polymorphic_on and polymorphic_identity to get specific class instances for a much larger number of events.

[YuriiMotov]

It's said in the docs:

Only inherit from data models, don't inherit from table models.

Source: https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/#only-inherit-from-data-models

So, according to the docs, it's supposed to be done the following way:

importsqlmodelclassBaseEvent(sqlmodel.SQLModel):
id: int=sqlmodel.Field(default=None, primary_key=True)
event_data: dict=sqlmodel.Field(default_factory=dict, sa_type=sqlmodel.JSON)
classEvent(BaseEvent, table=True):
passclassStartEvent(BaseEvent):
pass

[sneakers-the-rat]

There seems to be new additional breakage, but there have been longstanding problems with how sqlmodel deals with annotated types and FieldInfo - e.g. for as long as i've used it, if you have any functional validators in the annotated type, the Field will be ignored entirely (whether it was replaced with pydantic's version or not).

[vimota]

@YuriiMotov@svlandeg Any chance we could convert this to an Issue ? It seems like the latest version of SQLModel broke existing functionality and folks looking for this issue might miss it in Discussion (with an "accepted" answer)

[sneakers-the-rat]

Agreed. This is a package-breaking bug that would break any site that didn't have explicit tests for db constraints. A top-tier, highest-priority, nothing-works level bug. 3 weeks and you would just miss it if you looked in the issues as you would for any other package.

Respectfully, the system here and fastapi that seems to be designed to decrease triage time seems to backfire and require a bunch more triage work & slows PR velocity. I just run a private fork of sqlmodel and fastapi because the amount of work to fix bugs upstream isnt worth it, but would be happy to do so if there was a more normal issue/PR flow.

[YuriiMotov]

Converted to issue: #1623