New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
sqlalchemy-bot opened this Issue Jan 2, 2015 · 3 comments

Comments

Projects
None yet
1 participant
@sqlalchemy-bot

sqlalchemy-bot commented Jan 2, 2015

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

This comment has been minimized.

sqlalchemy-bot commented Jan 2, 2015

Changes by Michael Bayer (@zzzeek):

  • edited description
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 10, 2015

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 #259

00dae5f

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jan 10, 2015

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment