Formatting MigrationResults in a custom Provider about goose

[mfridman]

Alright, #668 has been merged. Feel free to give this a go and if you have opinions on the output drop a comment.

[mfridman]

I'd ideally call Up() in exactly the same way as the command line

I presume you'd like the same Go options to be exposed as CLI flags? Are you specifically looking for the "session locker", or anything in particular?

(Yes, next step is to swap out the NewProvider in the CLI code, which will enable us to expose many of those knobs).

I'd like a way the format MigrationResults in the same way as the normal up command.

Can you expand on this, are you looking to get more information in the goose up command? I presume if there was #350 support it'd be helpful here?

[mortenson]

An API like this is what I was thinking:

results, err := provider.Up(context.Background())
if err != nil {
	// Handle in whatever way, although maybe there should be a goose function here too.
}
// Could also return an array of strings for the caller to log
goose.PrintMigrationResults(results)

Where PrintMigrationResults would print output similar to or exactly the same as goose up, including the goose: no migrations to run. case. As I type this is seems a bit lazy to request, but as someone who only cares about whether or not Up() succeeded, the formatting of each MigrationResult doesn't matter much to me.

[mortenson]

(Yes, next step is to swap out the NewProvider in the CLI code, which will enable us to expose many of those knobs).

Neat - for my use case if the session locking could happen via CLI args, then I could just call goose.Run("up", ...) too.

[mfridman]

I'm a bit confused, are you using the goose CLI (as in, the pre-built binaries), or are you using the goose package directly?

Fwiw I was never a big fan of the goose.Run function, because it muddied the separation between goose as a package that can be imported within a Go project and the needs of the goose CLI.

Re. the above request, I think what you're looking for is some way to get back verbose logging that happened within the core goose functions like up, down, etc. I think the default should be no logging, but you can opt-in to it, which would eliminate the need for a custom function like PrintMigrationResults.

And if you're not happy with the goose log output, then the nice thing is you have access to []MigrationResult and can format/tune this however you like.

ps. I've been taking some time to reflect back on the state of the project, and next steps, so you'll see more activity soon-ish.

[mortenson]

Re. the above request, I think what you're looking for is some way to get back verbose logging that happened within the core goose functions like up, down, etc.

Yes, this is it! As I mentioned before this is a bit lazy, but to give you an idea of what I'm doing now here's a Gist: https://gist.github.com/mortenson/f2558c857d7e089813a4dc5138da9a67

It's really not that bad, just not something I need to maintain and also I doubt I'll know to make updates to it as behavior in Goose changes (ex: new fields in MigrationResult that are significant)

[mfridman]

Gotcha, thanks for the explanation. I think there are a few code paths we could add additional logging, and then from the Provider we expose 2 options:

1. (optional) WithLogger() .. need to think why this is even needed, but by default, it'd be the std lib logger like it is today. Iirc the most common reason is so folks could wrap their zap, zerolog, slog, etc. to get structured logging.
2. WithVerbose() .. this option would enable you to opt-in to more logging from within the goose package.

[mfridman]

I took a quick pass at this, and would like to get it in before the next release. I assume that output is enough for your needs.

#668

[mortenson]

Looks great @mfridman ! Thank for for taking the time to do this. And how silly I feel to not have realized that MigrationResult had a String method ... Still, I'm happy to defer the logging behavior to goose.

[mfridman]

I just recently added that in anticipation of this feature.

Will try to get something merged in the next day or two and cut a release.