Supporting multiple database engines (not binds) #562
-
|
What's the Right Way ™️ to go about supporting multiple database engines? For example, my Flask app supports both SQLite for small-scale installations and PostgreSQL for larger deployments, i.e.,
That lets deployers run Alembic upgrade commands without having to specify the database engine, which the Typer CLI detects and sets. Meanwhile, developers can generate a single revision that can upgrade/downgrade both supported engines. I want a similar UX for my Flask app, where I might run |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
As long as your migrations are generic and work on both databases, you don't have to do anything, because Flask-Migrate takes your SQLAlchemy URL and uses it to connect to your database. I do this for many of my projects, by the way. So basically, do not use database specific types in your migrations, and do not issue database specific SQL, and then everything should work. If you do need database specific logic in your migration scripts, then you will have to manually implement logic for both engines, and that will work too. |
Beta Was this translation helpful? Give feedback.
-
|
I really misunderstood how Alembic's multidb template worked. This is much simpler. Thank you! |
Beta Was this translation helpful? Give feedback.
As long as your migrations are generic and work on both databases, you don't have to do anything, because Flask-Migrate takes your SQLAlchemy URL and uses it to connect to your database. I do this for many of my projects, by the way.
So basically, do not use database specific types in your migrations, and do not issue database specific SQL, and then everything should work. If you do need database specific logic in your migration scripts, then you will have to manually implement logic for both engines, and that will work too.