Type | None not working when Type is a class

[darhsu]

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

from typing import TYPE_CHECKING, Optional

from sqlmodel import Field, Relationship, SQLModel

if TYPE_CHECKING:
    from .team_model import Team


class Hero(SQLModel, table=True):
    id: Optional[int] = Field(default=None, primary_key=True)
    name: str = Field(index=True)
    secret_name: str
    age: Optional[int] = Field(default=None, index=True)

    team_id: Optional[int] = Field(default=None, foreign_key="team.id")
    team: "Team" | None = Relationship(back_populates="heroes")

Description

• Error when running this code:

    team: "Team" | None = Relationship(back_populates="heroes")
          ~~~~~~~^~~~~~
TypeError: unsupported operand type(s) for |: 'str' and 'NoneType'

• Python 3.10 supports using Type | None
• The example code is pulled from the documentation here
• Is there a way to use "Team" | None without using Optional?

Operating System

macOS

Operating System Details

No response

SQLModel Version

0.0.18

Python Version

Python 3.10.13

Additional Context

No response

[tonjo]

I had the same issue, and I was forced to use Optional.
Out of curiosity, why don't you want to use it?

[darhsu]

I saw how Type | None is the preferred way in python 3.10+. Just wanted to make the codebase consistent by not using Optional

[joachimhuet]

Well you could use from __future__ import annotations to remove the quotes around Team but it's discouraged with sqlmodel because it causes other problems (#196)

Or you can from typing import Type and use Type["Team"] | None to make "Team" a type and not just a string.

Hope this helps

[darhsu]

Something interesting happened when I used Type["Team"] | None. I got a RecursionError:

Traceback (most recent call last):
  File "/workspaces/app.py", line 4, in <module>
    from sql.hero_model import Hero
  File "/workspaces/sql/hero_model.py", line 9, in <module>
    class Hero(SQLModel, table=True):
  File "/opt/conda/lib/python3.10/site-packages/sqlmodel/main.py", line 532, in __init__
    relationship_to = get_relationship_to(
                      ^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/lib/python3.10/site-packages/sqlmodel/_compat.py", line 159, in get_relationship_to
    return get_relationship_to(
           ^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/lib/python3.10/site-packages/sqlmodel/_compat.py", line 159, in get_relationship_to
    return get_relationship_to(
           ^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/lib/python3.10/site-packages/sqlmodel/_compat.py", line 159, in get_relationship_to
    return get_relationship_to(
           ^^^^^^^^^^^^^^^^^^^^
  [Previous line repeated 988 more times]
  File "/opt/conda/lib/python3.10/site-packages/sqlmodel/_compat.py", line 130, in get_relationship_to
    origin = get_origin(annotation)
             ^^^^^^^^^^^^^^^^^^^^^^
RecursionError: maximum recursion depth exceeded

[joachimhuet]

Oh sorry about that, I just tried and got the same thing... 😢 That was not a good advice ^^
The only way I found was to remove the if TYPE_CHECKING from the hero_model file and only keep it on the team_model file.

# hero_model.py
from sqlmodel import Field, Relationship, SQLModel

from .team_model import Team


class Hero(SQLModel, table=True):
    id: int | None = Field(default=None, primary_key=True)
    name: str = Field(index=True)
    secret_name: str
    age: int | None = Field(default=None, index=True)

    team_id: int | None = Field(default=None, foreign_key="team.id")
    team: Team | None = Relationship(back_populates="heroes")

# team_model.py
from typing import TYPE_CHECKING

from sqlmodel import Field, Relationship, SQLModel

if TYPE_CHECKING:
    from .hero_model import Hero


class Team(SQLModel, table=True):
    id: int | None = Field(default=None, primary_key=True)
    name: str = Field(index=True)
    headquarters: str

    heroes: list["Hero"] = Relationship(back_populates="team")

I am not sure why it does not work with SQLModel but it seems to work with pure pydantic objects:

# hero_model.py
from typing import TYPE_CHECKING
from pydantic import BaseModel

if TYPE_CHECKING:
    from .team_model import Team


class Hero(BaseModel):
    id: int | None = None
    name: str
    secret_name: str
    age: int | None = None
    team_id: int | None = None
    team: "Team | None" = None

# team_model.py
from typing import TYPE_CHECKING
from pydantic import BaseModel

if TYPE_CHECKING:
    from .hero_model import Hero


class Team(BaseModel):
    id: int | None = None
    name: str
    headquarters: str

    heroes: list["Hero"] = []

[darhsu]

@joachimhuet Definitely an interesting find -- I didn't get any errors with pure pydantic objects too. Do you think this issue is potentially a problem with sqlmodel?

[joachimhuet]

Mmh in fact I don't think it's a bug. It seems normal to not be able to use an object that has not yet been defined. By doing this if TYPE_CHECKING: ... we just import during type checking, meaning that we do not have access to the object yet. And probably, in Relationship there is a use of that.

And in fact for the example I gave using pure pydantic if you import Hero and instantiate Hero before importing Team you should have an error. This is also the case with the example from the documentation using Optional[Team] if you only import hero and try to instantiate a hero without giving it a team you will have the same KeyError: 'Team'. And having to keep in mind that a Team must be imported before the Hero can be used is troublesome.

In my projects what I do is the following:

• Have separate models for Base, Table, Read, Write, Update
• Have crud functions in a separate folder and by testing each crud separately I figure out if I have any dependencies that need to be imported directly in crud for the operations to work.

NOTE: Having several models for the same object is encourage because having only the Table you won't have pydantic validation activated. And in addition you won't be able to handle things like when I create a user I don't want to provide the whole team but just the team_id, but when I read a user I don't care about the team_id, I want the team object passed on, etc

I have a small project example with that structure but I did not face the import problem on this specific case.
https://github.com/joachimhuet/sqlmodel-project-example

And for my larger projects, having several types allows me to put them in other files to avoid recursive import. I have for example:

models\
  user\
    user_base.py          # Contains the base object
    user_table.py         # Contains the table object
    user_schemas.py    # Contains the Read, Write Update objects
    user_extras.py        # Contains extra objects like UserOnlyId, UserIdEmail ... 

It's very opinionated but I like having everything well separated and clear from the start, and this way Tables recursive import error do not affect the rest of my objects.