-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a "compact" command #105
Comments
In general I'm loathe to do anything that encourages referencing the committed migrations; these are not meant for human consumption and you should instead reference the DB directly or a pg_dump or similar. I'm also unsure how this would work with the migration tracking table in the database - especially remote databases such as staging/production, or other developers? |
I think that once the migration folder becomes too big to your taste (100 migrations? 1000? 10k?), it's still time to just:
It takes 5minutes, not too complicated for something I'd expect to do every man-year of work or so. But hard enough to not let any beginner do it and make a mess. On the other hand, having this as a command in Graphile migrate looks like a foot gun that could cause problems |
I should note that I have wanted a "squash"/"rebase" style feature before. Often you'll want something to end up being one migration, but whilst working on it you might want to commit phases (phase 1: insert new tables; phase 2: copy data over from old tables to new; phase 3: implement security and test it; phase 4: delete the original tables/etc). Ultimately you want this to be one commit, but due to the way you're manipulating the data within the tables you can't really do it idempotently. The ability to squash these 4 commits into one before you merge to master/ship would be neat. I've not evaluated what it'd involve yet, and it opens the same questions I had above (but with a much more obviously constrained use case). |
squash/rebase functionality – whether for a periodic compaction or a reconsideration of intentionally-staged commits yet to hit production – sounds awesome. One idea for implementation would be for Once the |
@ben-pr-p in your specific example you could implement a little script in |
Feature description
Add a command,
which compresses all of the migrations in
committed/
to one migration. I think this can be accomplished by running all the committed migrations on the shadow database and then dumping the output viapg_dump -c
, where-c
is the "clean" flag that includes statements to drop objects.Motivating example
Over time, you can accumulate a large number of committed migrations. This is mostly a non-issue, but when it has become an issue is when I'm redefining a function for the more than 2nd time.
I'll search my code for
CREATE OR REPLACE FUNCTION my_func_name
to find the latest definition, and occasionally I'll find an older version to redefine and accidentally re-introduce a change incidental to my intended change.Checking a dump mostly solves this, but it would be nice not to encounter it in the first place and to keep the committed migrations clean.
I'm also curious to see if other people have potential uses for this - not 100% committed to it being necessary / good.
Supporting development
I [tick all that apply]:
The text was updated successfully, but these errors were encountered: