You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, i'm very new to Alembic and i'm trying to test it with a very simple project.
Describe the bug
My database(Postgis) has 3 schemas: public, topology and tiger.
My own tables are in the public schema.
Running a first migration that adds a table 'users' is going well but when i try to make a new migration to add a single column, the migration script creates the whole users table again (with the new column) instead of just add the column to the users table.
I found theses issues: #1282 and #1416. Mine seems to be a combination of both.
Following answers from these issues, I've added this in my env.py:
# To not take into account postgis extra schemasdefinclude_name(name, type_, parent_names):
iftype_=="schema":
returnFalseelse:
returnTrue# ...context.configure(
connection=connection,
target_metadata=target_metadata,
include_name=include_name,
include_schemas=True
)
This is ok for not touching topology and tiger schemas when creating a new migration, but as i said the users table is recreated entirely.
If i remove the include_schemas and include_name arguments when calling context.configure, now the column is added correctly, without recreating the whole users table, but the migration script removes all tables in topology and tiger schemas.
Expected behavior
I would like to be able to have non default schema alongside the default one, add tables into the default schema without removing any tables from other schemas and when add or remove column from my own table, not recreate the whole table each time.
To Reproduce
The env.py is the one by default with these additions:
Error
Not an error per se but compare should not detect these when autogenerate a second migration
INFO [alembic.autogenerate.compare] Detected added table 'users'
INFO [alembic.autogenerate.compare] Detected added index ''ix_users_email'' on '('email',)'
INFO [alembic.autogenerate.compare] Detected added index ''ix_users_id'' on '('id',)'
INFO [alembic.autogenerate.compare] Detected added index ''ix_users_username'' on '('username',)'
Versions.
OS: OSX sonoma
Python: 3.10.2
Alembic: 1.13.1
SQLAlchemy: 2.0.29
Database: postgres 15.5 - postgis 3.4
DBAPI: psycopg 2.9.9
Additional context
Have a nice day!
The text was updated successfully, but these errors were encountered:
Hello, i'm very new to Alembic and i'm trying to test it with a very simple project.
Describe the bug
My database(Postgis) has 3 schemas: public, topology and tiger.
My own tables are in the public schema.
Running a first migration that adds a table 'users' is going well but when i try to make a new migration to add a single column, the migration script creates the whole users table again (with the new column) instead of just add the column to the users table.
I found theses issues: #1282 and #1416. Mine seems to be a combination of both.
Following answers from these issues, I've added this in my env.py:
This is ok for not touching topology and tiger schemas when creating a new migration, but as i said the users table is recreated entirely.
If i remove the include_schemas and include_name arguments when calling context.configure, now the column is added correctly, without recreating the whole users table, but the migration script removes all tables in topology and tiger schemas.
Expected behavior
I would like to be able to have non default schema alongside the default one, add tables into the default schema without removing any tables from other schemas and when add or remove column from my own table, not recreate the whole table each time.
To Reproduce
The env.py is the one by default with these additions:
After running
alembic revision --autogenerate -m "Initial migration"
Uncomment the phone_number field in User from models.py
After running
alembic revision --autogenerate -m "add phone number"
Error
Not an error per se but compare should not detect these when autogenerate a second migration
Versions.
Additional context
Have a nice day!
The text was updated successfully, but these errors were encountered: