False positives in alembic revisions

[diego-pm]

The linter gives a false positive in version numbers from alembic revision.

For example, the filename daa52d289898_description.py is corrected to data52d289898_description.py
and the revision numbers included in the file also give a false positive:

"""Description...

Revision ID: daa52d289898  # `daa` should be `data`
Revises: d1a839b16d12
Create Date: 2025-02-18 12:10:22.253105
"""
...
# revision identifiers, used by Alembic.
revision = "daa52d289898"  # `daa` should be `data`
down_revision = "d1a839b16d12"
branch_labels = None
depends_on = None
...

[epage]

Note that the template you filled out was specifically geared towards english words and does not make sense with other forms of identifiers.

It would also be good to define what an alembic revision as its not something I've ever come across.

If this is just another form of sha, we have #415 and #484.

[diego-pm]

It seems that the issues you mentioned could also solve this, but this case has more information, so it might be easier to identify that the revision is a false positive, as the migration scripts follow a certain structure.

Alembic is a tool, used along sqlalchemy, to manage database schema migrations. Basically, an alembic revision is a python script that handles the upgrade/downgrade operations of a database schema migration.

The revision number or revision id is like a unique identifier of the database schema version. I think it is like an UUID or maybe some hash, not sure at all.

[epage]

this case has more information,

Could you define that format?

Alembic is a tool, used along sqlalchemy, to manage database schema migrations. Basically, an alembic revision is a python script that handles the upgrade/downgrade operations of a database schema migration.

The question I then have is whether this is something general enough to include built-in support for or if this should be left to user config via extend-ignore-identifiers-re or extend-ignore-re

[diego-pm]

The example code I show is the structure of alembic migration scripts. Also, the scripts always have 2 functions: upgrade and upgrade. And the filename always follows the 12 digit identifiers with some description.

Here is an example provided by the documentation https://alembic.sqlalchemy.org/en/latest/tutorial.html

"""Add a column

Revision ID: ae1027a6acf
Revises: 1975ea83b712
Create Date: 2011-11-08 12:37:36.714947

"""

# revision identifiers, used by Alembic.
revision = 'ae1027a6acf'
down_revision = '1975ea83b712'

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.add_column('account', sa.Column('last_transaction_date', sa.DateTime))

def downgrade():
    op.drop_column('account', 'last_transaction_date')

But it is true that maybe this is too specific, and should be left to the user to exclude these patterns. The PR to detect hashes and UUIDs might be more general.

[epage]

The example code I show is the structure of alembic migration scripts. Also, the scripts always have 2 functions: upgrade and upgrade. And the filename always follows the 12 digit identifiers with some description.

I was less asking about the file format as we won't deal with that but the format of each of the non-words being treated as words.

For example, you mentioned the filename has a 12 digit identifier. Is it always data<hash>_*.py?

The PR to detect hashes and UUIDs might be more general.

We do have those already but we have at least #415. Our word splitting would not catch data<hash>. #484 could help.

[diego-pm]

The format of the non-words is the base 16 number (hash), there is no data (in general) in the non-word. The file name is generally <hash>_*.py.

[epage]

Sounds like this is then a duplicate of #415 and closing in favor of that.