2015-09-21 18:31 GMT-07:00 Mike Bayer <mike...@zzzcomputing.com>:
>
> OK great, I can now show something similar happening. Your model has
> tables t1 and t2 in *both* the public and notifications schema and I'm
> assuming the same foreign key setup.
>
> In many of your examples I've observed the explicit use of "public":
>
> __table_args__ = {'schema': 'public'}
>
> That has to be removed entirely. When I have all four tables and I use
> "public" explicitly, the reflection system cannot get enough information to
> make a decision, based on the information in the section I originally
> referred to at
> http://docs.sqlalchemy.org/en/rel_1_0/dialects/postgresql.html#remote-schema-table-introspection-and-postgresql-search-path
> - see the yellow sidebar box at the bottom of the section for a quick
> summary.
>
> When I remove the redundant "public" schema from my table defs, the
> redundant FK defs go away.
>
Mmmm, but:
- Before each test, I was dropping all the tables on the 'public' and
'notifications' schemas, and I made sure they were empty. So there should
never be both tables on both schemas.
- Each time, I was running alembic twice: first time to create the tables
(and I checked that they were on the expected schema), second time to
experience the dropping/recreation of keys.
I agree that the first snippets that I copy-pasted were confusing, so I
decided to limit the tests just to the env.py I attached previously,
dropping the tables for a clean state. In this code I am only referencing
to 'notifications' with "__table_args__ = {'schema': 'notifications'}", and
'public' is never used. With it, t1, t2 and alembic_versions are created
all on 'notifications', an nothing in 'public'.
Could you reproduce that?
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
