Any way to get alembic check to take pending migrations into account?

[cjw296]

I'm looking for an alembic equivalent of Django's makemigrations --check.

Alembic's check command isn't quite this, it appears to be more like Django's migrations --check.

The use case I have is to ensure that pull requests haven't changed database models in such a way that an alembic migration should have been included in the PR. What's working for folks in this area at the moment?

If I run alembic check with correctly generated and up-to-date migrations, I still get:

$ alembic check
INFO  [alembic.runtime.migration] Context impl MySQLImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
ERROR [alembic.util.messaging] Target database is not up to date.
  FAILED: Target database is not up to date.

I'm looking for something that I can run that will take into account the unapplied migrations and only fail if someone forgot to generate one.

[CaselIT]

Hi,

there is the check command that should to what you are looking for https://alembic.sqlalchemy.org/en/latest/api/commands.html#alembic.command.check

[cjw296]

@CaselIT - not quite, I've added more detail in the original post, but as I said, alembic check works like Django's migrate --check, I want something that works like [makemigrations --check](https://docs.djangoproject.com/en/5.0/ref/django-admin/#cmdoption-makemigrations-check)

[cjw296]

On 13/03/2024 10:17, Federico Caselli wrote: Hi, there is the check command that should to what you are looking for https://alembic.sqlalchemy.org/en/latest/api/commands.html#alembic.command.check <https://alembic.sqlalchemy.org/en/latest/api/commands.html#alembic.command.check>

Almost, but not quite... #1441 Chris

[zzzeek]

What are people doing in the meantime?

they run their DB migrations in their CI environments, which everyone should do anyway

What's the timeline for Alembic 2.0?

nonexistent, there are no plans for this

("autogen from persisted metadata" doesn't sound like what I'm after - I'm basically looking for "does the state of the database plus pending migrations end up with the schema for the model")

I am sure Django is not looking at the "state of the database" since they dont have any of the reflection capabilities of SQLAlchemy / Alembic. I would assume they are looking at the current revision number in the DB and assuming that part is present.

The "autogen from persisted metadata" idea is fairly vague so far and does not include that it would serialize each known state of the DB as diffs, but it could do that just as well. What it can't do is link individual database migration operations to known schema states, because alembic migrations are open ended, there can be plain execute() calls and such. IIUC, Django's models and migration operations are rigidly constrained to the subset of "django patterns" that are available, so they can link individual migration operations to model changes in a 1-1 fashion.

[CaselIT]

("autogen from persisted metadata" doesn't sound like what I'm after - I'm basically looking for "does the state of the database plus pending migrations end up with the schema for the model")

if you are you ok with modifying the target database you can achieve this by doing alembic upgrade heads && alembic check.

if not then it's currently not possible as explained above

[cjw296]

I am sure Django is not looking at the "state of the database" since they dont have any of the reflection capabilities of SQLAlchemy / Alembic. I would assume they are looking at the current revision number in the DB and assuming that part is present.

A quick skim over their code suggest they load the state from the database and diff the models. I think their migrations table stores more info than is in the alembic_migrations table.

states, because alembic migrations are open ended, there can be plain execute() calls and such. IIUC, Django's models and migration operations are rigidly constrained to the subset of "django patterns" that are available,

They also have raw sql stuff in their migrations, so face the same problem, and I think it's reasonably to caveat these as "not covered."

[CaselIT]

The issue is not what the migration table contains or not.
Alembic uses schema diffs comparing the database state with the models state. This means that the db needs to have all migration applied to have a meaningful comparison.
Django as far as I know compares a serialized version of the models with the current models state, so no db is required for such operation.

[zzzeek]

They also have raw sql stuff in their migrations, so face the same problem, and I think it's reasonably to caveat these as "not covered."

right but then you have metadata structures unaccounted for, which would then show up as false positives. if they are building up the state of their migration by summing the individual migration operations and linking them directly to a model, then model structures that were generated by non-standard means will be missed. in django this is probably fine because the models are extremely limited in what they can include in any case. SQLAlchemy models can have anything, EXCLUDE constraints, etc.

it would be sufficient to store a structure that represents the actual state of the metadata at different versions, which can produce diffs which then streams into migration operations. mostly like what we have, just that we dont use reflection to generate the "current DB state".