✨ Support sqlmodel_rebuild

[adsharma]

The @sqlmodel decorator introduced by fquery.sqlmodel moves schema definitions and types closer to the object model (references) instead of foreign_keys.

Instead of writing:

class Hero(SQLModel, table=True):
    ...
    team_id: int | None = Field(default=None, foreign_key="team.id")

you could write:

@sqlmodel
class Hero:
    ...
    team: Team | None = foreign_key("team.id")

Everything works the same as before. Only the syntax has changed. However, if Team also has a foreign key to Hero, then one of them will have to use forward declaration so type checkers work.

In those cases we need a two pass solution where in the second pass, with the full type definition available, we can generate the correct code.

Refactor some of the existing code to introduce sqlmodel_rebuild().

[adsharma]

@svlandeg I think there were some merge errors in one of the commits in this thread.

The following should show changes to only sqlmodel/main.py. However, I see other deltas.

git diff 83629f6 7d00768 --stat
 .github/workflows/publish.yml   |  2 +-
 .github/workflows/smokeshow.yml | 12 +-----------
 .github/workflows/test.yml      | 11 ++---------
 docs/databases.md               |  2 +-
 docs/release-notes.md           |  6 ------
 sqlmodel/main.py                | 17 +----------------
 6 files changed, 6 insertions(+), 44 deletions(-)

[svlandeg]

@svlandeg I think there were some merge errors in one of the commits in this thread.

The following should show changes to only sqlmodel/main.py. However, I see other deltas.

The diff on this PR only shows changes in sqlmodel/main.py. That said, the CI has not been green at any point throughout the commits of this PR. This should be fixed before the PR is taken out of draft and marked as ready for review.

As you can see, the tests for Pydantic v1 are failing. This needs to be addressed before we can properly review this PR. Thanks! 🙏

[adsharma]

The diff on this PR only shows changes in sqlmodel/main.py

That's the inconsistency I'm calling out. What the UI shows and git diff commit1 commit2 show are different and I believe that's causing the test failures.

I'm thinking I'll close this and create a new PR as a workaround.

[adsharma]

I looked into the pydantic_v1 test failures a bit. There are 3 different instances of the test:

~/src/sqlmodel/docs_src/tutorial/fastapi/app_testing$ ls -1d tut*
tutorial001
tutorial001_py310
tutorial001_py39

If I run pytest in each individual directory, they all pass. However, if I try to turn pytest in the parent directory, it tries to load the Hero class from tutorial001 and then again an identically named class in tutorial001_py310 and fails exactly the same way as CI. Please note that this is happening at test collection time, even before tests are executed.

I can reproduce this behavior on the main branch as well. So the question becomes how were these tests passing before my changes?

[svlandeg]

I can reproduce this behavior on the main branch as well. So the question becomes how were these tests passing before my changes?

Hm, that's puzzling to me as well, as the tests do seem to succeed just fine on other recent PRs for this repo 🤔

[adsharma]

@svlandeg the above test run verifies that the pydantic-v1 breakage was caused by my change.

Looking into the actual cause of the failure, I think there is some __call__ magic happening on the call to __do_init__() that I don't completely understand. The problem is that classname argument is different before and after the change.

Solving this boils down to figuring out how to correctly invoke __do_init__() so the behavior is the same as before.

[adsharma]

@svlandeg tests are all green. Please review.