feat(experimental): add collect migrations logic #615
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the
Source
type that represents SQL and Gp migrations files found in the file system.Source files are an intermediate representation that gets merged with registered Go migrations to return a Migration object. (this is an internal implementation detail, most users don't need to know this).
This implementation keeps parity with the existing code, with 3 notable exceptions:
Provider
. Previously, we used to gather all the migrations but failed ONLY if/when running the migration, which leads to partial errors at runtime. Note, that the existing implementation remains as-is, only the Provider code is different.Specifically, this check:
goose/migration.go
Lines 103 to 105 in fe8fe97
goose.WithGo
andgoose.WithGoNoTx
options to register migrations directly into the provider instead of relying on theinit()
registration functions.This is particularly useful for DI codebases that create a closure over the Go migration functions to pass down configs, other clients, etc.
goose.WithExcludes
as an option. Feature request: baseline/ignore migrations #431One thought I had as I was implementing this is it becomes the caller's responsibility to know how to work with
fs.FS
.I do think it's way more flexible for the caller, e.g., using
embed.FS
orfs.Sub
, and it becomes less for goose to maintain, i.e., having an explicit dirpath and afs.FS
.