I had this exact same issue – I don’t know if it still affects you. For me, the problem was caused because the schema I was using was not the default – I think the same thing is happening for you, since you’re using a “Products” schema. I posted an issue at: https://bitbucket.org/zzzeek/alembic/issue/281/autogenerate-fails-to-detect-existing And with … Read more
alembic revision –autogenerate inspects the state of the connected database and the state of the target metadata and then creates a migration that brings the database in line with metadata. If you are introducing alembic/sqlalchemy to an existing database, and you want a migration file that given an empty, fresh database would reproduce the current … Read more
After a bit of experimentation using @velochy’s answer, I settled on something like the following pattern for using SqlAlchemy inside Alembic. This worked great for me and could probably serve as a general solution for the OP’s question: from sqlalchemy.orm.session import Session from alembic import op # Copy the model definitions into the migration script … Read more
To add, you’d need: https://alembic.sqlalchemy.org/en/latest/ops.html#alembic.operations.Operations.create_unique_constraint from alembic import op op.create_unique_constraint(‘uq_user_name’, ‘user’, [‘name’], schema=”my_schema”) To drop, you’d need: https://alembic.sqlalchemy.org/en/latest/ops.html#alembic.operations.Operations.drop_constraint op.drop_constraint(‘uq_user_name’, ‘user’, schema=”my_schema”)
You can set the PYTHONPATH environment variable to control what python sees as the top level folder, eg. if you are in the root folder of your project: PYTHONPATH=. alembic revision -m “…” Then you can use a “normal” import in your alembic env.py, relative to your root folder, in your example: from src.models.base import … Read more
Why real values in DB are ‘DRAFT’, ‘APPROVE’, ‘PUBLISHED’, but not draft, etc? I supposed there should be ENUM values, not names. As Peter BaĊĦista’s already mentioned SQLAlchemy uses the enum names (DRAFT, APPROVE, PUBLISHED) in the database. I assume that was done because the enum values (“draft”, “approve”, …) can be arbitrary types in … Read more
Finally I solved the problem. Created raw sql to fetch the values and used bulk_insert. def upgrade(): ### commands auto generated by Alembic – please adjust! ### op.create_table(‘client_credential’, sa.Column(‘id’, sa.Integer(), nullable=False), sa.Column(‘created_at’, sa.DateTime(), nullable=False), sa.Column(‘updated_at’, sa.DateTime(), nullable=False), sa.Column(‘client_id’, sa.Integer(), nullable=False), sa.Column(‘key’, sa.String(length=22), nullable=False), sa.Column(‘secret’, sa.String(length=44), nullable=False), sa.Column(‘is_active’, sa.Boolean(), nullable=False), sa.ForeignKeyConstraint([‘client_id’], [‘client.id’], ), sa.PrimaryKeyConstraint(‘id’), sa.UniqueConstraint(‘key’) ) … Read more
It turns out there’s a very simple, pragmatic solution to this: alembic upgrade <target-revision> || alembic downgrade <target-revision>
I also was in the same situation: alter primary key. In my case, I had to change the primary key type from integer to string. The primary key also had a foreign key relationship to another table. The earlier alembic migration created the foreign key constraint in the following way: #!/usr/bin/python3 from alembic import op … Read more
Looks like I found the answer on reddit’s /r/flask. Comment by u/executex from discussion Alembic autogenerate column changes? in flask Just add “compare_type=True” to context.configure() parameters inside your env.py’s “run_migrations_online” function. context.configure( connection=connection, target_metadata=target_metadata, compare_type=True )