constraint names in 'alembic upgrade --sql' do not get naming_convention treatment

Question

Migrated issue, originally created by Marek Baczyński ()

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.add_column('some_table', sa.Column('deleted', sa.Boolean(name='deleted'), nullable=False))
    ### end Alembic commands ###


def downgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.drop_column('some_table', 'deleted', mssql_drop_check=True)
    ### end Alembic commands ##

Result:

$ alembic upgrade head --sql
INFO  [alembic.migration] Context impl MSSQLImpl.
INFO  [alembic.migration] Generating static SQL
INFO  [alembic.migration] Will assume transactional DDL.
BEGIN TRANSACTION;

CREATE TABLE alembic_version (
    version_num VARCHAR(32) NOT NULL
);

GO

INFO  [alembic.migration] Running upgrade None -> 4fdd79043216, added deleted column to some_table
-- Running upgrade None -> 4fdd79043216

ALTER TABLE some_table ADD deleted BIT NOT NULL;

GO

-- expected ck_some_table_deleted
ALTER TABLE some_table ADD CONSTRAINT deleted CHECK (deleted IN (0, 1));

GO

INSERT INTO alembic_version (version_num) VALUES ('4fdd79043216');

GO

COMMIT;

The constraint name is OK when actually performing the upgrade.

该提问来源于开源项目：sqlalchemy/alembic

Answer 1

Michael Bayer () wrote:

• ensure that target_metadata is also present in the offline migration context, so that --sql mode gets access to naming conventions also. existing environments need to add target_metadata to the offline migration context manually. fixes #189

→ efdf9e408fb1