add ability to replace golang migration registry with custom one #351
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Yes that will help but I would prefer something simpler that we could leverage without breaking change. |
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 9, 2022
All migration code is now in a Provider that provides migrations funcationally. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backwards compatable, and does not break the current Public API. This is accomplished by aliasing the Public functions to a defaultProvider that is initalized to the default settings as it is currently. Those who don't which to use the new funcationally can do so without and changes need. Those who need to care to use the new system, need to Initalize a new Provider via the `goose.NewProvider()` methods which will return a provider that will be initalize to the default settings, unless otherwise overwritten. Note: No new tests where added, and the test were purposely left* alone so to insure that the API did not break. * except for runMigrationSQL as that is a private api. Since, behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the defailtProvider. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 9, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't which to use the new functionality can do so without and changes need. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` methods which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 9, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't wish to use the new functionality can do so without any changes. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` method which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 9, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't wish to use the new functionality can do so without any changes. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` method which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 9, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't wish to use the new functionality can do so without any changes. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` method which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 9, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't wish to use the new functionality can do so without any changes. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` method which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 16, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't wish to use the new functionality can do so without any changes. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` method which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 25, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't wish to use the new functionality can do so without any changes. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` method which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
gdey
added a commit
to gdey/goose
that referenced
this pull request
Jun 25, 2022
All migration code is now in a Provider that provides migrations functionality. This helps isolate various parts of the migrations and prevents multiple migrations from stepping on top of each other. This refactor is completely backward-compatible and does not break the current Public API. This is accomplished by aliasing the Public functions to a `defaultProvider` that is initialized to the default settings as it is currently. Those who don't wish to use the new functionality can do so without any changes. To use the new system, one will need to Initialize a new Provider via the `goose.NewProvider()` method which will return a provider that will be initialized to the default settings, unless otherwise overwritten. Note: No new tests were added, and the tests were purposely left* alone so to ensure that the API did not break. * except for runMigrationSQL as that is a private API. Since behavior did not change, this means all the race conditions that existed before still exists, just now isolated to the `defailtProvider`. See: * pressly#351 * pressly#114 * pressly#114 (comment)
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I'm trying to run goose as lib for several services, and I want to run several migrations from code. Still, the issue is that we can't achieve this because multiple migrations will be registered simultaneously to the same registry.
Here is some example.
I have service A with go migration 0001_initial.go
I have service B with go migration 0001_initial.go
we import both methods to the init database, and we have a conflict.
another example
I have service A with go migration 0001_initial.go
I have service B with go migration 0001_somtehings.go
we import both methods to the init database, and we have a conflict in versions that don't work well.
I tried to implement something very simple. We can register migrations to a custom registry and then set this registry before we run any goose code.