Thanks for your quick responses. We have never downgraded our prod
database, but I feel it's still nice to have that option.
I was just thinking While I'm thinking there needs to be one migration
that merges 2 versions, and in my mind it has to work on both
repositories That's not
just so you know, surgical-precision downgrades will be more reliable once we
get the 1.6 series of Alembic out, where we have a total rewrite of how the
internal traversal works in order to make upgrade/downgrades across complex
trees more reliable. downgrades are not *too* common in
c787 did not fail, nor did 60e8 on upgrade. According to alembic history,
alembic ran 1efb before c787. So the result is I have a view in my
database that will never get used because the query is now embedded in
code. The solution is clear. 60e8 should drop a view if there is one.
For
On Tue, Mar 9, 2021, at 5:06 PM, 'br...@derocher.org' via sqlalchemy-alembic
wrote:
> I'm wondering how to solve an issue.
>
> One developer created migration 1efb
>
> upgrade:
> drop view v1 -- moved to query in the code
>
> downgrade:
>create view v1 as select 1
>
> Another
I'm wondering how to solve an issue.
One developer created migration 1efb
upgrade:
drop view v1 -- moved to query in the code
downgrade:
create view v1 as select 1
Another developer created a migration c787
upgrade:
create or replace view v1 as select 2
downgrade
create or replace
