Getting empty migrations with application factory pattern

[flixman]

I have the following project structure:

myapp
├── app.py
├── backend
│   ├── __init__.py
│   └── models
│       ├── model1.py
│       ├── model2.py
│       └── __init__.py
├── frontend
└── app.py

inside backend/init.py, I do:

from backend.models import db
from flask_migrate import Migrate
migrate = Migrate()

def create_app() -> Flask:
    [...]
    db.init_app(app)
    migrate.init_app(app, db)
    with app.app_context():
        db.create_all()
    [...]

And in inside backend.models.init.py, I have:

from backend.models.db import db
from backend.models.model1 import Model1
from backend.models.model2 import Model2

__all__ = ["db", "Model1", "Model2"]

I want to keep the migrations folder inside backend, and I am using the factory pattern in app.py. If I call the initialization of flask-alembic like

flask db init -d backend/migrations

I get the folder created where I want it, however, when then I call

flask db migrate -d backend/migrations

What I get back is, I think, an empty migration:

INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
INFO  [alembic.env] No changes in schema detected.

This is the first time I am using Alembic, as well as Flask-Alembic, so most likely I am doing something wrong... but I cannot point out what. Can somebody give me a hand?

[miguelgrinberg]

Are you importing your models? SQLAlchemy registers your models when they are imported. If you do not imported your models anywhere then they are not seen.

[flixman]

Ok, I have tried it and I have gone a bit further: if I keep in my create_app only this:

def create_app() -> Flask:
    """Creates the flask app, configures it and returns it"""
    app = Flask(__name__, static_folder='../frontend/build')
    db.init_app(app)
    migrate.init_app(app, db)

And then I execute

flask db init -d backend/migrations
flask db migrate -m "Initial migration." -d backend/migrations
flask db upgrade -d backend/migrations

I do an upgrade of the models and then I run again

flask db migrate -m "After modifications" -d backend/migrations
flask db upgrade -d backend/migrations

I do see the scripts created in versions, and after the upgrade I see the tables in the postgresql db. However, if I drop the database and run the flask application, the tables that were previously created by db.create_all()... they are not created anymore. What am I missing on this setup? It is annoying because as part of my unit tests I create random db, one per test, that I expect them to be populated by my create_app method, and now all tests are failing.

[miguelgrinberg]

Migrations are used to upgrade your database without losing your data. For temporary databases that are created from scratch such as those used in unit tests, you can call create_all(), which is actually faster. If you aren't yet, you must configure your application to use different databases for development, testing and production. If you don't see a need to do this, then using database migrations is also going to seem unnecessaily complicated.

[flixman]

I was thinking in doing this, but then a doubt came to mind: I know that with create_all the models will be properly instantiated in the DB, which means that if there is any error in the upgrade scripts I will not catch it until I upgrade the db in testing or production. Because of this I was thinking in using the upgrade on the unit tests also... do you think there is no point in that?

[miguelgrinberg]

What I have done in many projects is use create_all() for all the tests, but then add one more test that does the following:

• populates a brand new database by running through the migrations (i.e. it runs flask db upgrade or the equivalent Python function)
• attempts to create a new migration and ensures that the new migration comes up empty (i.e. runs flask db check or similar Python function)

[flixman]

I will explore this route then. Thank you!