Conversation
VojtechVitek
left a comment
There was a problem hiding this comment.
LGTM. Thank you! 🎉
Link back to the original discussion: #768
|
Alright @VojtechVitek, merged. Was going to cut a release this weekend (but if you need it sooner let me know). Surprisingly, I have some time, so I would like to squeeze a few more things in the next release. Oh, and I suppose we need to be careful about changing attribute keys since they may be used by end-users in handler options. |
|
@mfridman no rush. Up to you :) Perhaps we can export |
Yeah, had a similar thought. I suspect these become part of the public API surface indirectly, so they could be exposed. Maybe we add E.g., // Log key constants for structured logging. These keys are used in slog output and can be used by
// consumers to parse or filter log entries.
const (
LogKeyLogger = "logger"
LogKeyCurrentVersion = "current_version"
LogKeySource = "source"
LogKeyDirection = "direction"
LogKeyDurationSeconds = "duration_seconds"
LogKeyState = "state"
LogKeyVersion = "version"
LogKeyType = "type"
LogKeyStatement = "statement"
) |
|
Looks good. The top-level pkg sounds fine too 👍 |
This PR adds a
WithSlogprovider option.A bit more maintenance on maintainers to compose both sets of messages. But I think this should be okay, we don't log a lot via the provider.
Full example:
{ "time": "2025-09-17 23:05:23", "level": "INFO", "msg": "executing statement", "logger": "goose", "source": "00001_users_table.sql", "statement": "<omitted>", "type": "sql", "version": 1 } { "time": "2025-09-17 23:05:23", "level": "INFO", "msg": "migration completed", "logger": "goose", "direction": "up", "duration_seconds": 0.000857834, "source": "00001_users_table.sql", "state": "applied", "type": "sql", "version": 1 }