Re: Switching between schema branches in alembic

I'm quite curious about why you need to maintain all these different versions of the same database. Like in code, you branch out to be able to do development in parallel without interfering other development, and eventually you merge back. But here it seems you want to keep multiplying the number

Re: Switching between schema branches in alembic

I see... Ok, then I think that what you are actually doing is not going back b1, b2, etc., but something slightly different, which we could name c1, c2, etc. These migrations are going to be very similar to the "b" branch, so you can reuse probably a good amount of code, but adapting them to start

Re: Switching between schema branches in alembic

Hi Andy, As you said, it is not a merge, more like a "checkout". To accomplish that with alembic, you would need to downgrade (see https://alembic.sqlalchemy.org/en/latest/tutorial.html#downgrading) from a4 back to root, and then upgrade up to b4. On Mon, May 3, 2021 at 10:22 AM AndyS wrote:

Re: Drop followed by generation of Foreign Keys

2015-09-22 11:52 GMT-07:00 Sergi Pons Freixes <sachiel2...@gmail.com>: > 2015-09-22 10:41 GMT-07:00 Mike Bayer <mike...@zzzcomputing.com>: > >> >> So one more time, with all detail possible; attached is an env.py script >> and a full log of all SQL emitted a

Re: Drop followed by generation of Foreign Keys

2015-09-22 10:44 GMT-07:00 Mike Bayer <mike...@zzzcomputing.com>: > > > 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': >

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

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 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-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 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 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'] > >

Drop followed by generation of Foreign Keys

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'