drop_constraint etc. should check for name=None and emit informative error message since this is common w/ autogenerate

I made migration with alembic revision --autogenerate which contains addition of foreign key:

def upgrade():
    # ### commands auto generated by Alembic - please adjust! ###
    op.create_table('image_resource',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('url', sa.String(length=250), nullable=False),
    sa.PrimaryKeyConstraint('id')
    )
    op.add_column('category', sa.Column('image_id', sa.Integer(), nullable=True))
    op.create_foreign_key(None, 'category', 'image_resource', ['image_id'], ['id'])
    # ### end Alembic commands ###


def downgrade():
    # ### commands auto generated by Alembic - please adjust! ###
    op.drop_constraint(None, 'category', type_='foreignkey')
    op.drop_column('category', 'image_id')
    op.drop_table('image_resource')
    # ### end Alembic commands ###

Upgrade works great, but when I tried to downgrade I got issue: if len(ident) > self.max_identifier_length: TypeError: object of type 'NoneType' has no len() at sqlalchemy/engine/default.py, line 444.

If I manually specify foreign key it works perfectly:

op.create_foreign_key('my_fk', 'category', 'image_resource', ['image_id'], ['id'])

op.drop_constraint('my_fk', 'category', type_='foreignkey')

Is this behaviour is issue?

Reproduce the downgrade failure from the generated migration and trace op.drop_constraint and the related drop_* operations into the path reaching sqlalchemy/engine/default.py line 444. Done means passing None as a constraint name produces an informative error instead of the TypeError shown, while explicitly named constraints continue to work.