autogenerate migration issues of constraints across schemas #1290
-
EDIT: The naming conventions seems to be not the cause, I suspect the cause might be foreignkeys across multiple (postgres) schemas. I followed this steps: https://alembic.sqlalchemy.org/en/latest/naming.html#integration-of-naming-conventions-into-operations-autogenerate to add naming conventions for autogenerate, as without naming conventions the name is left to None, and the drop_constraint would not work. After introducing the naming constraints the autogenerate successfully generated the constraints. However, the next autogenerate migration will drop the constraints and readd them, also adds one of the constraints twice... I would expect the following autogenerate migrations to not drop and create the constraints again.
initial autogenerated migration:
next autogenerated migration:
Versions.
Looks like related to this comment in another topic: #916 (comment) (However, I could not find an issue that was created based on that comment.) |
Beta Was this translation helpful? Give feedback.
Replies: 11 comments 6 replies
-
Update: Tried specifying the constraint names explicitly, therefore removing the naming convention as possible cause. |
Beta Was this translation helpful? Give feedback.
-
Hi, The schema seems different. Please ensure that the search path is the same between different runs of alembic |
Beta Was this translation helpful? Give feedback.
-
Hi, I tried to setup a minimal example: |
Beta Was this translation helpful? Give feedback.
-
looking at the example, you are doing things that are not really supported, like changing the value of |
Beta Was this translation helpful? Give feedback.
-
Sorry for the delay: leaving the first migration looks fine, but the second migration will create the "test" table as if it does not know about it yet, of course resulting in "already exists" errors. |
Beta Was this translation helpful? Give feedback.
-
Also, I only used |
Beta Was this translation helpful? Give feedback.
-
Can you share also the log that's printed by alembic? |
Beta Was this translation helpful? Give feedback.
-
For reference, I took the example mentioned earlier, and just left out the
|
Beta Was this translation helpful? Give feedback.
-
just overall I see "set search_path to "myschema"" happening, we have a standard approach for search path that is recommended which is documented at https://docs.sqlalchemy.org/en/20/dialects/postgresql.html#remote-schema-table-introspection-and-postgresql-search-path . if this convention is not being followed, then autogenerate will very likely not do the right thing. we have one recipe that includes changing the search path which is at https://alembic.sqlalchemy.org/en/latest/cookbook.html#rudimental-schema-level-multi-tenancy-for-postgresql-databases . This recipe requires that So as far as what we support, search_path should not be modified outside of its default of "public" if include_schemas is used. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your input. The original reason why I modified the search path is the following: If there is a better approach for my usecase I am happy to try. |
Beta Was this translation helpful? Give feedback.
-
To summarize:
Thanks to @zzzeek and @CaselIT for your suggestions and help. |
Beta Was this translation helpful? Give feedback.
To summarize:
I could solve the problem for my usecase by:
default_schema_name
__table_args__
to{"schema": None}
object.schema
to!= None
Thanks to @zzzeek and @CaselIT for your suggestions and help.