autogen erroneously gens constraints using column.key, but we don't render "key =" in Column

[sqlalchemy-bot]

Migrated issue, originally created by Michael Bayer (@zzzeek)

given:

Table(
    't1', target_metadata,
    Column('t1_id', Integer, key='id', primary_key=True),
)

Table(
    't2', target_metadata,
    Column('t2_id', Integer, key='id', primary_key=True),
    Column('t2_t1id', Integer, key='t1id'),
    ForeignKeyConstraint(['t2_t1id'], ['t1.t1_id'])
)

alembic autogens incorrectly as:

    op.create_table('t2',
    sa.Column(u't2_id', sa.Integer(), nullable=False),
    sa.Column(u't2_t1id', sa.Integer(), nullable=True),
    sa.ForeignKeyConstraint(['t1id'], ['t1.id'], ),
    sa.PrimaryKeyConstraint('id')
    )

that is, without "key='x'" in the columns, but the constraints refer to the .key names. We should not render "key='x'" though, because the ForeignKeyConstraint will generate in DDL as referring to 't1.id', which does not exist, because operations._ensure_table_for_fk has no idea that 't1' has a different name than 'id' that's stated directly in the constraint.

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• edited description

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

• The rendering of a :class:~sqlalchemy.schema.ForeignKeyConstraint
  will now ensure that the names of the source and target columns are
  the database-side name of each column, and not the value of the
  .key attribute as may be set only on the Python side.
  This is because Alembic generates the DDL for constraints
  as standalone objects without the need to actually refer to an in-Python
  :class:~sqlalchemy.schema.Table object, so there's no step that
  would resolve these Python-only key names to database column names.
  fixes autogen erroneously gens constraints using column.key, but we don't render "key =" in Column #259

→ 00dae5f

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to closed