Re: Drop followed by generation of Foreign Keys

2015-09-22 11:52 GMT-07:00 Sergi Pons Freixes : > 2015-09-22 10:41 GMT-07:00 Mike Bayer : > >> >> So one more time, with all detail possible; attached is an env.py script >> and a full log of all SQL emitted and commands; we have alembic_version is

Re: Drop followed by generation of Foreign Keys

2015-09-22 10:44 GMT-07:00 Mike Bayer : > > > On 9/22/15 1:41 PM, Sergi Pons Freixes wrote: > > Additional update: If on the env.py I substitute "__table_args__ = > {'schema': 'notifications'}" for "__table_args__ = {'schema': > 'notifications'}" and rerun alembic twice

Re: Drop followed by generation of Foreign Keys

2015-09-22 10:41 GMT-07:00 Mike Bayer : > > So one more time, with all detail possible; attached is an env.py script > and a full log of all SQL emitted and commands; we have alembic_version is > created in "public", the two tables created only in "notifications", no >

Re: Drop followed by generation of Foreign Keys

On 9/22/15 2:25 PM, Sergi Pons Freixes wrote: 2015-09-22 10:44 GMT-07:00 Mike Bayer >: On 9/22/15 1:41 PM, Sergi Pons Freixes wrote: Additional update: If on the env.py I substitute "__table_args__ = {'schema':

Re: Drop followed by generation of Foreign Keys

On 9/22/15 1:41 PM, Sergi Pons Freixes wrote: Additional update: If on the env.py I substitute "__table_args__ = {'schema': 'notifications'}" for "__table_args__ = {'schema': 'notifications'}" and rerun alembic twice again (assuming we start on a clean database), alembic_version is created

Re: Drop followed by generation of Foreign Keys

Additional update: If on the env.py I substitute "__table_args__ = {'schema': 'notifications'}" for "__table_args__ = {'schema': 'notifications'}" and rerun alembic twice again (assuming we start on a clean database), alembic_version is created on the 'notifications' schema, t1 and t2 on

Re: Drop followed by generation of Foreign Keys

On 9/22/15 3:43 PM, Sergi Pons Freixes wrote: 2015-09-22 11:52 GMT-07:00 Sergi Pons Freixes >: 2015-09-22 10:41 GMT-07:00 Mike Bayer >: So one more time, with

Re: Drop followed by generation of Foreign Keys

2015-09-22 16:24 GMT-07:00 Mike Bayer : > Revision runs fine, but now when I run the upgrade it does not find the > alembic_version table (attached logs)... I suspect that the search_path is > restored so that it takes notifications again by default? > > > yes > > >

Re: Drop followed by generation of Foreign Keys

On 9/22/15 6:49 PM, Sergi Pons Freixes wrote: 2015-09-22 15:06 GMT-07:00 Mike Bayer >: OK, the only possible way this would happen is if "SELECT current_schema()" were returning the name "notifications", and I went back