Re: Drop followed by generation of Foreign Keys

2015-09-23 Thread Mike Bayer
On 9/22/15 7:38 PM, Sergi Pons Freixes wrote: 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

Re: Drop followed by generation of Foreign Keys

2015-09-22 Thread Sergi Pons Freixes
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 Thread Sergi Pons Freixes
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 Thread 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 > created in "public", the two tables created only in "notifications", no >

Re: Drop followed by generation of Foreign Keys

2015-09-22 Thread Mike Bayer
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

2015-09-22 Thread 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 again (assuming we start on a clean database), alembic_version is created

Re: Drop followed by generation of Foreign Keys

2015-09-22 Thread Sergi Pons Freixes
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

2015-09-22 Thread Mike Bayer
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 Thread Sergi Pons Freixes
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

2015-09-22 Thread Mike Bayer
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

Re: Drop followed by generation of Foreign Keys

2015-09-21 Thread Sergi Pons Freixes
2015-09-21 16:13 GMT-07:00 Mike Bayer : > > Are you sure you don't have any in-application event handlers or similar > manipulating search_path? Can you put this in your env.py and tell me > what it says? > > with connectable.connect() as connection: > >

Re: Drop followed by generation of Foreign Keys

2015-09-21 Thread Mike Bayer
On 9/21/15 6:09 PM, Sergi Pons Freixes wrote: 2015-09-21 14:18 GMT-07:00 Mike Bayer >: OK, I'm still not able to reproduce (see attached), as long as include_schemas=True. However, in your env.py, you have this:

Re: Drop followed by generation of Foreign Keys

2015-09-21 Thread Mike Bayer
On 9/21/15 8:14 PM, Sergi Pons Freixes wrote: 2015-09-21 16:55 GMT-07:00 Mike Bayer >: Can you run the above with logging enabled? That is the [alembic] logger turned on as in the default alembic.ini. Sure thing, this

Re: Drop followed by generation of Foreign Keys

2015-09-21 Thread Mike Bayer
On 9/21/15 7:32 PM, Sergi Pons Freixes wrote: 2015-09-21 16:13 GMT-07:00 Mike Bayer >: Are you sure you don't have any in-application event handlers or similar manipulating search_path? Can you put this in your env.py

Re: Drop followed by generation of Foreign Keys

2015-09-21 Thread Sergi Pons Freixes
2015-09-21 16:55 GMT-07:00 Mike Bayer : > Can you run the above with logging enabled? That is the [alembic] logger > turned on as in the default alembic.ini. > Sure thing, this was the output: $ alembic -c development.ini revision -m "upgrade" --autogenerate

Re: Drop followed by generation of Foreign Keys

2015-09-21 Thread Sergi Pons Freixes
2015-09-21 14:18 GMT-07:00 Mike Bayer : > > > > OK, I'm still not able to reproduce (see attached), as long as > include_schemas=True. However, in your env.py, you have this: > > def include_symbol(tablename, schema): > return schema == table_args['schema'] > >

Re: Drop followed by generation of Foreign Keys

2015-09-19 Thread Mike Bayer
On 9/18/15 7:43 PM, Sergi Pons Freixes wrote: Hi everybody, I am experiencing the same issue commented here: https://bitbucket.org/zzzeek/alembic/issues/293/alembic-autogenerate-creates-endless In my case, I have the model: ---8<-- ... class EmailAttachment(Base):

Drop followed by generation of Foreign Keys

2015-09-18 Thread Sergi Pons Freixes
Hi everybody, I am experiencing the same issue commented here: https://bitbucket.org/zzzeek/alembic/issues/293/alembic-autogenerate-creates-endless In my case, I have the model: ---8<-- ... class EmailAttachment(Base): __tablename__ = 'email_attachment'