Closed tauseef13bok closed 10 months ago
The behavior your seeing is related to not doing dependency order resolution for the alembic DropOp
When resolution order is a problem the best bet is to break the migration down into smaller chunks:
For example, you could
alternatively, you could continue dropping both at the same time and manually re-order the drop_entity
calls in the autogen'ed migration
Possible approaches to solving this upstream (if you'd like to submit a PR would be to update here https://github.com/olirice/alembic_utils/blob/fb39689d3b5204f049b44c8ca662bc6a0802d605/src/alembic_utils/replaceable_entity.py#L391-L400
To
upgrade_ops
equivalent to https://github.com/olirice/alembic_utils/blob/fb39689d3b5204f049b44c8ca662bc6a0802d605/src/alembic_utils/depends.py#L13where either implementation would need tests like this one https://github.com/olirice/alembic_utils/blob/master/src/test/test_depends.py
Hi .I created a fork , to solve the dependency ordering . My fork supports ordering of nested dependencies for both create and drop operation. Could you have a look?
If you could open a PR an annotate the changes I'd be happy to take a look!
Sure. done.
I created a trigger and a function on which the trigger operates. then i changed the signature of trigger and function . Now as function depend on trigger , first trigger should be dropped and then function ... But strangely in migration files sometimes first trigger is dropped and then functions and sometimes first function and then triggers which is causing errors when upgrading db.
I have attached three files . In triggers.py file triggers and functions are defined ...pl. just keep changing the signatures of func and trig and re run the migration 3 4 times .. Desktop.zip