Speed up status command and sort output

[ble]

Fixes #282

• Commit 1 retrieves migration application timestamps in ListMigrations(), which requires updating every db-specific querier;

• Commit 2 uses the updated ListMigrations() to retrieve status of all migrations in a single db query;

• Commit 3 sorts the output of goose status so

  • applied migrations are sorted by the timestamp of their application
  • pending migrations are sorted to the end
    • per an earlier comment about out-of-order migration application.

[ble]

Should I try to address those linter failures by replacing the old-style // +build tags with the newer //go:build tags?

[ble]

I tried running the lint check on my own machine and got some unfortunate looking errors. 🤞

[ble]

Rebased to main + added spanner support, identified as a problem by the last merge+integration test suite CI run. 🤞

[ble]

Anything else I can help with or provide?

[mfridman]

Anything else I can help with or provide?

Nope, I've been going back and forth on the behavior. Specifically, whether it's a good idea to modify the default sort order. There's a bit of a decision to make because if the issues below ever get implemented, "grouped migrations" might have the same timestamp.

#222
#485

(In Postgres, we have tstamp timestamp NOT NULL DEFAULT now() and now() has the same timestamp within the transaction, so we need to take that into account.)

Granted, your PR handles this case, because it checks the timestamp and if the same, sorts by version.

I think for now, we should keep the existing behaviour and default listing by version number. We can still roll forward with the List query, just modify the sort. Wdyt?

The idea is that in the future, we can add a --sort flag to the goose status command, which defaults to version id (today's behavior) but can be changed with a --sort=timestamp (which is your implementation).

The latter is probably useful for those running out-of-order migrations, and they can choose which sorting method they prefer.

---

By timestamp order (this PR d295509, pending always goes last)

Applied At                  Migration
=======================================
Wed Nov 19 13:13:23 2025 -- 00001_table.sql
Wed Nov 19 13:13:23 2025 -- 00002_insert.sql
Wed Nov 19 13:13:23 2025 -- 00003_alter.sql
Wed Nov 19 13:13:23 2025 -- 00005_no_tx.sql
Wed Nov 19 13:13:23 2025 -- 00006_complex.sql
Pending                  -- 00004_empty.sql

After goose up

Applied At                  Migration
=======================================
Wed Nov 19 13:13:23 2025 -- 00001_table.sql
Wed Nov 19 13:13:23 2025 -- 00002_insert.sql
Wed Nov 19 13:13:23 2025 -- 00003_alter.sql
Wed Nov 19 13:13:23 2025 -- 00005_no_tx.sql
Wed Nov 19 13:13:23 2025 -- 00006_complex.sql
Wed Nov 19 13:37:21 2025 -- 00004_empty.sql. <--- timestamp order

[mfridman]

TL;DR - let's create 2 functions sortByTimestamp (your current PR) and sortByVersion (current behavior), and keep the current behavior the default. But use the List query to speed things up, WDYT?

In the future, we can add a --sort and give users the option to choose. Flipping between the 2 functions.

[ble]

sounds good to me! I thought about sort orders but I thought I would keep it simple for the first pass.

[ble]

• Changed the status command's default sort order to migration version (or migration source if versions are identical);
• Added a flag to switch status command's sort order to by application time;
• Rebased onto main to resolve conflicts.

[ble]

Just be frank if you hate the name of the sort order flag, that's easy to change ;-)

[ble]

... and if you'd rather have the new sorting flag split out into a separate PR, I can do that, too.

[mfridman]

Sorry for all the back forth. Crazy time end of year wrapping up projects.

If you could split the cli stuff that'd be great. The main changes here that are nice to get in are the improved list stuff

[ble]

If you could split the cli stuff that'd be great. The main changes here that are nice to get in are the improved list stuff

👍👍

I just took the last commit off and also rebased to the latest changes in main.

There's no flag to change sorting order and no function implementing the alternate sorting order.

[ble]

erk, I needed to push 1 more commit to get rid of that sort-order function.