Closed underbluewaters closed 3 years ago
I’ve not yet had a sufficiently compelling reason to implement this, but basically I was planning to let some kind of meta header --!
indicate the hash should be trusted without verification.
Assuming your migrations haven’t actually ran what I would do is repeatedly graphile-migrate uncommit
, move the migration somewhere you can later restore (e.g. git stash, but only the current file/folder, not the committed migrations) and repeat until you’re back to where prod is. Then do the reverse, fixing the migrations as you go.
Ah thanks for the suggestion. I didn't think about running uncommit multiple times. I'll try that and report how it goes. A meta header would be easier but I think this should help me out of this situation.
Using git stash
was an elegant solution to getting this done. I was able to run the following commands in zsh to zip over to the offending migrations and apply a fix.
repeat 18 { npx graphile-migrate uncommit & git stash current.sql }
After going through a few migrations line by line doing the stash pop & commit manually, applying everything again was as easy as
repeat 14 { git stash pop & npx graphile-migrate commit }
Thanks for sharing :+1:
Using repeat
in combination with graphile-migrate
and git stash
is a neat trick! Here's what I had to do to get this working (on macOS with git 2.30.1 in my case):
repeat 8 { ./scripts/graphile-migrate.sh uncommit && git stash push -- migrations/current.sql }
Note that I'm running this in the project root (where the .gmrc
file is located). In my case git stash
expected a pathspec with a path to the migrations
directory.
Editing committed migrations now possible via https://github.com/graphile/migrate/pull/114
Yes, I'd like to do a bad thing but hear me out. Now that I'm deploying my database on RDS I'm finding some inconsistencies in behavior between RDS and my local version of postgres. Migrations fail because some contain some questionable modifications to the contents of pg_catalog.pg_enum to make edits to an enum type more idempotent. Several of my committed migrations going back many iterations do this and so now I'm stuck. I could get into the details but I'm not sure it much matters.
I'm not seeing any documented means to alter a committed migration and update the related hash. I'm also not sure what the implications would be if I were to do that. I understand this is not something that should be encouraged but I believe finding incompatibilities with a deployment target is probably a legitimate (and fairly common?) reason someone might want to do this.