aleph CLI command to downgrade the postgres DB#3858
Conversation
| def channel_tag(obj, clazz=None): | ||
| clazz = clazz or type(obj) | ||
| if clazz == str: | ||
| if clazz is str: |
There was a problem hiding this comment.
This is not related, but my local ruff installation complained about it 🤷
7505714 to
f0667d5
Compare
tillprochaska
left a comment
There was a problem hiding this comment.
Thank you, works as expected :) Added one suggestion about a dry-run option below.
aleph/manage.py
Outdated
| @cli.command() | ||
| @click.option( | ||
| "--revision", | ||
| "-r", | ||
| default="-1", | ||
| show_default=True, | ||
| help="target revision number. Can also be 'head' or '-1'", | ||
| ) | ||
| def downgrade_database(revision): | ||
| """Downgrade the database.""" | ||
| downgrade_db(revision) |
There was a problem hiding this comment.
Running database downgrades can be quite scary as they can delete data. The core alembic CLI has a dry-run option and I just checked and Flask-Migrate exposes that, too.
| @cli.command() | |
| @click.option( | |
| "--revision", | |
| "-r", | |
| default="-1", | |
| show_default=True, | |
| help="target revision number. Can also be 'head' or '-1'", | |
| ) | |
| def downgrade_database(revision): | |
| """Downgrade the database.""" | |
| downgrade_db(revision) | |
| @cli.command() | |
| @click.option( | |
| "--revision", | |
| "-r", | |
| default="-1", | |
| show_default=True, | |
| help="target revision number. Can also be 'head' or '-1'", | |
| ) | |
| @click.option( | |
| "--sql", | |
| default=False, | |
| is_flag=True, | |
| help="...", | |
| ) | |
| def downgrade_database(revision, sql): | |
| """Downgrade the database.""" | |
| downgrade_db(revision, sql) |
Something like this should print the SQL statements the migration would execute without actually executing it, as well as the names of the migrations that will be rolled back.
This would allow us to double check that the downgrade is doing what we expect before actually executing it.
There was a problem hiding this comment.
When I tested this locally, I accidentally rolled back a different migration than I expected… 😄
There was a problem hiding this comment.
I made these changes:
- the default is a dry run, which prints a warning that this doesn't actually execute, the migration and the SQL statements and quits.
- you now have to pass
--executeto actually run the migrations.
Remove debug print Remove debug print statements Add an explicit execute flag, default to dry run
f0667d5 to
8506338
Compare
No description provided.