Add `update` subcommand to update number

[perrito666]

update sub-command

Rationale

Oftentimes many of us in the same project add migrations using tern as a tool and, upon merging one pull request, all others need to update the number of their proposed patches. This is something that might happen more if one is working in a long lived branch.

Proposed solution

I added an update command which allows to re-number an existing migration.

• It will fail if the migration is not duplicated (or it would cause a missing migration)
• It will only change the number part (cannot rename)

Collateral additions

• I added a function that checks dupes and missing migrations in the schema folder, might be useful for something else so I made it a standalone function.
• With this I propose a new way to check dupes and missing migrations that I suspect might be more accurate than the one used already but I did not dare replace it because I was not sure I understood it in full.

[jackc]

I've run into the same inconvenience when merging branches that each have migrations, and I would like to improve the process.

If I understand your proposal correctly given a situation where there existed the following migrations:

001_create_foo.sql
001_create_bar.sql

Then you would run the command:

tern update 001_create_bar.sql

And it would rename 001_create_bar.sql to 002_create_bar.sql.

I like the idea of tooling to solve this problem. This is a improvement over:

mv {001,002}_create_bar.sql

The update command figures out what the next available migration is -- but I think more can be done.

---

Here's a few rough ideas of other potential solutions.

1. An interactive mode that shows all duplicates and the user chooses which one to renumber. This would save a lot of time and typing when their are multiple duplicate migrations to merge.

2. Some sort of integration with git. In theory it should be possible tell tern which branches are being merged and it to figure out what to rename. OTOH, that is tied to git and it might be difficult to handle all the merge and rebase strategies people use.

3. We could have 2 commands designed to work together. The first command captures what the current migrations are. Then the second command finds all the new duplicates and renames them. e.g.

tern renumber_duplicates start
git merge feature-branch-with-migrations
tern renumber_duplicates finish

tern could persist state in a temp file.

I think ideas 1 and/or 3 would be even easier to use than the update command as is.

[perrito666]

I suspect 1 would be the more agnostic. It would fit most scenarios. We could alternatively add a flag so people that don't want interactive can just pass the ones they want forward migrated. Ill work something and come back so we can see if it goes in the right direction :)

edit: (sorry just realized that I had used the wrong number so I changed it so my comment makes sense)

[perrito666]

did not forget about this, just life got in the middle, ill come back to this soon

[perrito666]

lol, i came back to finally address this and found that you already implemented a way better version in v2 :) sorry for dragging for so long and thank you for the amazing addition