Autogenerate detected removed index, for constraints

[sqlalchemy-bot]

Migrated issue, originally created by John Kida (@jkida)

(Postgresql)
It appears everywhere I have a constraint in my sqlalchemy code in which there is a unique constaint index alembic --autogenerate wants to remove it.

ie.
python code:
lead_id = Column(Integer, ForeignKey('crm_lead.id'), unique=True)

DataBase \d:
Indexes:
"chat_pkey" PRIMARY KEY, btree (id)
"chat_lead_id_key" UNIQUE CONSTRAINT, btree (lead_id)

INFO [alembic.autogenerate.compare] Detected removed index 'chat_lead_id_key' on 'chat'

It appears alembic does not consider constraints as indexes, and psql does.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

we tried really hard to get this right and there is a significant, explicit effort to make sure PG's uniques/indexes line up, including tests for this specific pattern (see https://bitbucket.org/zzzeek/alembic/src/85a21ed6cc637efc2e9705a30d397a194acb9742/tests/test_autogenerate.py?at=master#cl-818, https://bitbucket.org/zzzeek/alembic/src/85a21ed6cc637efc2e9705a30d397a194acb9742/tests/test_autogenerate.py?at=master#cl-911).

so knowing what PG version and what SQLAlchemy version here (assuming you're on the latest Alembic) would be helpful.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

I'm testing over here and I'm not seeing it. Using a model like this:

from sqlalchemy import MetaData, Table, Column, Integer, String, ForeignKey

target_metadata = MetaData()

Table('t', target_metadata, Column('id', Integer, primary_key=True))

Table('t2', target_metadata, Column('id', Integer, primary_key=True),
            Column('t1id', Integer, ForeignKey('t.id'), unique=True))

I run autogenerate for rev 1 and as expected we get this:

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.create_table('t',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.PrimaryKeyConstraint('id')
    )
    op.create_table('t2',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('t1id', sa.Integer(), nullable=True),
    sa.ForeignKeyConstraint(['t1id'], ['t.id'], ),
    sa.PrimaryKeyConstraint('id'),
    sa.UniqueConstraint('t1id')
    )
    ### end Alembic commands ###

run that upgrade. So now, we have the unique constraints in the DB (which PG sees as indexes) and we have the unique=True in the model, which I also made sure I applied on an FK column as you have above. run autogenerate again, I get:

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    pass
    ### end Alembic commands ###

So need all the data here - PG/SQLA/alembic versions, and also SQL output of what you get when you run alembic revision --autogenerate, at least some portion illustrating how it's coming up with or without indexes, uniques etc.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

just to check, as I notice your constraint appears to be named on the PG side, I gave it a name in my test:

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.create_table('t',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.PrimaryKeyConstraint('id')
    )
    op.create_table('t2',
    sa.Column('id', sa.Integer(), nullable=False),
    sa.Column('t1id', sa.Integer(), nullable=True),
    sa.ForeignKeyConstraint(['t1id'], ['t.id'], ),
    sa.PrimaryKeyConstraint('id'),
    sa.UniqueConstraint('t1id', name="t1id_uq_key")
    )
    ### end Alembic commands ###

the constraint remains unnamed when I use "unique=True". but a run against that still had the right answer, as we compare the indexes/constraints on the names of the columns within, if either side has no name.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

specifically, if you run this for a particular table with a unique, you should see results for both indexes and unique constraints:

>>> from sqlalchemy import create_engine, inspect
>>> e = create_engine("postgresql://scott:tiger@localhost/test")   
>>> insp = inspect(e)
>>> insp.get_unique_constraints("t2")
[{'column_names': [u't1id'], 'name': u't1id_uq_key'}]
>>> insp.get_indexes("t2")
[{'unique': True, 'name': u't1id_uq_key', 'column_names': [u't1id']}]
>>> 

otherwise it is sounding like those constraints were created on the DB side as "unique index" alone - the fact that they are named on the DB side and not in your Python side suggests a mismatch between your model and what's actually in the DB. if you add "index=True" to those columns, then you'll get a unique index without the UNIQUE constraint in the Python model.

If I run a test like this, e.g. first I create the schema using "unique=True, index=True" on the column. then I remove the "index=True" part, then I run another autogenerate, I get:

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.create_unique_constraint(None, 't2', ['t1id'])
    op.drop_index('ix_t2_t1id', 't2')
    ### end Alembic commands ###

which in fact is correct - by removing "index=True", it means I no longer want an index, i want just the unique constraint. which PG then creates as a pair of "unique constraint" / "index" as it does, but that's fine. the schema and model are remaining consistent with each other.

please confirm these are in fact just unique indexes in your PG database and that there's not an actual unique constraint, e.g. that adding index=True resolves, and we can close this, thanks !

[sqlalchemy-bot]

John Kida (@jkida) wrote:

I am running SQLAlchemy 0.8.0 , PostgreSQL 9.1.10

I tried running the test you mentioned, but it looks like i dont have a get_unique_contraints() method in SA 0.8.0

lead_id = Column(Integer, ForeignKey('crm_lead.id'), unique=True)

In [5]: insp.get_indexes('chat')
Out[5]: [{'column_names': [u'lead_id'], 'name': u'chat_lead_id_key', 'unique': True}]

PG sees this as type = index, so that looks correct to me.

This column was always ONLY a unique contraint, it was never a index=True.
However, I cant be sure of the naming you mentioned..
Is it possible that maybe. it was named before, when the DB was created, then the name was removed... I believe you tested the oposite, ie. unnammed, created db, then named.

Im not sure i understand exactly what I should confirm, I believe these are unique constraints.. the DB shows

Indexes:
    "chat_pkey" PRIMARY KEY, btree (id)
    "chat_lead_id_key" UNIQUE CONSTRAINT, btree (lead_id)
Foreign-key constraints:
    "chat_lead_id_fkey" FOREIGN KEY (lead_id) REFERENCES crm_lead(id)

They should be just unique constraints, im just not sure why autogenerate is appearing to want to remove them, or thinks it needs to drop an index.

Sorry if this wasnt helpful i can try to do some testing to reproduce it, from scratch.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

OK the first thing to understand is that when a "UNIQUE CONSTRAINT" is created on postgresql, PG will automatically create an additional UNIQUE INDEX at the same time. So generating a schema with "unique=True" means that PG will report on two constraints - one is "UNIQUE CONSTRAINT" and the other "UNIQUE INDEX". so that's the confusion that the new index comparison feature has to deal with.

Next, I didn't realize yesterday that we didn't even port the "unique constraint" feature to 0.8 at all, and there's no good reason for that so this is now backported to 0.8.4. So for the moment, your issue should resolve if you try out 0.8.4, which I can release later in the week if needed. you can get current 0.8 at https://bitbucket.org/zzzeek/sqlalchemy/get/rel_0_8.zip - let me know if the issue is resolved if you get the chance to try it out.

[sqlalchemy-bot]

John Kida (@jkida) wrote:

Mike,
I upgraded to SA rel_0_8 (8.4dev ) using the zip you provided the link to, and it is now recognizing the PG index contraints correctly. Everything seems to be working as expected with the SA upgrade. Is everything still in line to get 8.4 pushed to PyPi this week?

Thanks for the great work!

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

hi john -

this would normally be very early to push 0.8.4 but since this issue is going to hit everyone using alembic I'll try to get it out by the weekend.

• mike

[sqlalchemy-bot]

rachidb (@rach) wrote:

This ticket seem to be focus on Postgres.
We met a similar with 0.6.1 issue with one of our project which alas use MySQL.
Is 0.8.4 SQLAlchemhy is going to fix the issues on MySQL too?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

not sure, any chance you want to try it out for me?

[sqlalchemy-bot]

Zeyi Fan (@fanzeyi) wrote:

Same issue here.

Not PSQL, I use MySQL.

[sqlalchemy-bot]

Zeyi Fan (@fanzeyi) wrote:

I have a issue with MySQL that is similar to this issue, so I report it here.

Before start:

I'm new to alembic, and I'm not familiar with some concepts in database.

Library version:

Python 2.7.5

Mako==0.9.0
MarkupSafe==0.18
MySQL-python==1.2.4
SQLAlchemy==0.8.4
alembic==0.6.1

MySQL 5.6.10
Mac OS X 10.9.1

All codes below runs inside virtualenv and uses InnoDB as database engine.

Two parts:

I. Database Structures:

class User(Base):
    __tablename__ = "user"
    id = Column(Integer, primary_key=True)
    name = Column(String(30), index = True, unique = True) # PROBLEM HERE

Problem:

When I run alembic auto-generate first time, It seems normal. But when I run it again (just after upgrading the database, nothing changed), it will get op.drop_constraint(u'ix_user_name', 'user'). This would be failed.

I solved it by removing the index = True (it seems misused.)

II. Database Structures:

class User(Base):
    __tablename__ = "user"
    id = Column(Integer, primary_key=True)
    name = Column(String(30), unique = True)

class Thing(Base):
    __tablename__ = "thing"
    id = Column(Integer, primary_key = True)
    owner_id = Column(Integer, ForeignKey('user.id')) # PROBLEM HERE

Problem:

Like part I, generate it, upgrade it and re-generate it. I got op.drop_index('owner_id', 'thing'). It would cause exception Cannot drop index 'owner_id': needed in a foreign key constraint. Nothing changed except upgrading the database.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

I've identified issues with this logic in the current master due to a related fix, but the issue is not in 0.6.1.

if you've removed "index=True", that would be why you're getting a drop_constraint() - that flag is why there is an "ix_user_name" in the first place. put the index=True back in the Column. I will add additional tests to ensure no net change is detected.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

confirmed that the dedupe logic which takes place for PG has to be completely reversed for MySQL, which instead of reporting uniques as indexes, reports indexes as uniques. I'm rewriting the whole index autogenerate feature right now.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

i've reproduced and corrected for all the MySQL issues here in 40351ce, which also reworks the entire system to accommodate quirks across all of SQLite, Postgresql, MySQL.