Skip to content

Ensure SQLModel and SQLAlchemy Alembic migration parody with automated tests.  #19

@peterHoburg

Description

@peterHoburg

First Check

  • I added a very descriptive title to this issue.
  • I used the GitHub search to find a similar issue 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

NA

Description

Add tests that implement the same model in SQLModel and SQLAlchemy, then runs an Alembic migration against an array of databases. This is one way to find disparities in the underlying models generated by SQLModel.

Using Alembic to test the generated models deltas is a good real-world test. Moving from existing SQLAlchemy models to SQLModel's and running migrations is going to be a very common use case.

Wanted Solution

Create a set of isolated docker containers that run sets of Alembic migrations and see if there are any deltas.

Example workflow:

  • Spin up Postgres 13
  • Auto-generate an alembic migration based on the SQLAlchemy schema
  • Apply the Alembic migration to the DB
  • Auto-generate another alembic migration based on the SQLModel schema
  • Ensure that Alembic does not think there should be any migrations.

This could be done on a set of different DBs that SQLAlchemy supports.

Wanted Code

NA

Alternatives

Directly comparing the generated SQLAlchemy and SQLModel model's could be a solution, but it lacks the real-world use case and added complexity of using Alembic.

Operating System

Linux

Operating System Details

Docker

SQLModel Version

0.0.4

Python Version

3.9

Additional Context

I would be happy to set up these types of tests as this is my exact real-world use case.

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions