It doesn’t generate the migration from the model. You must duplicate your code in the migration using the SQLAlchemy notation that Alembic preferers. So, you create the model and create the migration with a type of SQLAlchemy notations that is a more object-oriented notation, not standard DDL, so you aren’t using a standard; you are using a quasi version of DDL which is enforced with the SQLAlchmy object model for these types of tasks (C# also has this type of notation, but it’s machine-generated after the Migrations looks at the model and how the model is decorated.) Java uses DDL for more enterprise migration tools.

  1. So you have your model.
  2. You create your migration to match your model.
  3. Your tables are created by Alembic (if it finds an Alembic table, it uses that for context; if it can’t find an Alembic table, it starts at the beginning. If it finds the table but doesn’t find the migrations in the right state, it blows chunks, and it usually means you have to pull your repo from the origin and pull down the latest and greatest actual migration.
  4. Once migrations are all run, you have a clean db, you can run the app, and it will be able to connect to the db without issues.
  5. Or you can run a script or program to put your db in a certain data state for very contextualized targeted testing, or you can do that by interacting with your App, API, or both.

Features that I think are a bit much, but it’s only because I’ve never used them in other migration tools and my lack of appreciation for them and feeling it was a bit over the top and that the feature could just have been documented as a perpetually kicking can road map item could end up sealing my fate in becoming at proficiently using them because of extraordinary mitigating circumstances that as it turns out are not that extraordinary because they ended up happening anyway. Perpetually kicking the can down the road product road map item, no pun intended. Had to come back to that one! Are the following::

  1. Partial Revision Identifiers - self-explanatory
  2. Relative Migration Identifiers - only if you did main frame programming, retire you Jackass!
  3. History Range View - What!

In all of these, just changing the i to an x instead of picking the one in the history that has exit correctly spelled in the comments will do just fine!!

Source::

Tutorial — Alembic 1.11.1 documentation

I just learned that the hybrid ORM I’m using called SQLModel incorporates db creation as Alembic does, only it doesn’t incorporate the db versions, which would be more enterprizee but I don’t need it. The code is as easy as https://sqlmodel.tiangolo.com/tutorial/code-structure/ In header Database File:: def create_db_and_tables(): SQLModel.metadata.create_all(engine)