Before any further exploration, here are a few pros&cons of the migration which we may already guess:
- Pro: We make table definitions more homogeneous. Right now we have several cases where we had to use sqlalchemy directly even in a SQLModel table declaration (example).
- Pro: We benefit from a large amount of on-line resources.
- Pro: In principle we could remove some tech debt by removing a lot of vendored sqlmodel/fastapi-users code and relying on the supported sqlalchemy/fastapi-users support.
- Con: The cost of the migration.
- Con: We may end up adding some more validation schemas (although, for the record, we typically already define and use
XXXCreate schemas).
The two options we see are:
- We rewrite all existing tables in sqlalchemy, in a way that does not require any migration (or, possibly, only some trivial ones). This is the golden solution, since a new deployment would be fully transparent (restart the app in the new version, and everything works out of the box), and it does not involve any intermediate phase with coexisting solutions. Note that this likely means that we also move to the supported sqlalchemy/fastapi-users integration.
- We proceed with incremental changes, where old tables remain in sqlmodel and new tables are in sqlalchemy only. This may work, but it's a hybrid solution and it could introduce additional complexity (e.g. in testing). Existing examples:
Some additional references:
To do: explore one of the two solutions. This is meant to be an exploration, to better assess whether a given approach is promising. The option of not migrating at all should also be considered valid.
NOTE: If solution 2 seems to work, then we could also adopt an intermediate approach where we support both sqlalchemy and sqlamodel but we only migrate table definitions from sqlmodel to sqlalchemy one at the time - incrementally.
Before any further exploration, here are a few pros&cons of the migration which we may already guess:
XXXCreateschemas).The two options we see are:
Some additional references:
To do: explore one of the two solutions. This is meant to be an exploration, to better assess whether a given approach is promising. The option of not migrating at all should also be considered valid.
NOTE: If solution 2 seems to work, then we could also adopt an intermediate approach where we support both sqlalchemy and sqlamodel but we only migrate table definitions from sqlmodel to sqlalchemy one at the time - incrementally.