[HUB-4300] Introduce Versioned Migration Flow#10
Draft
tholst-d4l wants to merge 15 commits intomainfrom
Draft
Conversation
7090301 to
7ccb9b5
Compare
- Restore legacy MigrationFunc + golang-migrate path alongside versioned flow - Guard against configuring both legacy and versioned functions - Tighten before/after script discovery (conflicts error) - Lint/test fixes
LRueckert
reviewed
Feb 26, 2026
Contributor
There was a problem hiding this comment.
I feel this doesn't warrant its own test file? Could just be a test case in the other test file.
Comment on lines
+30
to
+44
| if err != nil { | ||
| t.Fatalf("unexpected error: %v", err) | ||
| } | ||
| if dirty { | ||
| t.Fatalf("expected dirty=false") | ||
| } | ||
| if needsRecordTarget { | ||
| t.Fatalf("expected needsRecordTarget=false") | ||
| } | ||
| if version != 0 { | ||
| t.Fatalf("expected version 0, got %d", version) | ||
| } | ||
| if len(setter.forced) != 0 { | ||
| t.Fatalf("expected no Force calls, got %v", setter.forced) | ||
| } |
Contributor
There was a problem hiding this comment.
Again bringing up require and assert
| } | ||
|
|
||
| // CreateAfterSourceFolder returns a temp folder containing only non-before migrations. | ||
| func CreateAfterSourceFolder(sourceFolder string) (string, func(), error) { |
Contributor
There was a problem hiding this comment.
This function is never used, only tested. I assume an old approach?
| } | ||
|
|
||
| // CreateAfterSourceFolderForVersion returns a temp folder with the after migration for a single version. | ||
| func CreateAfterSourceFolderForVersion(sourceFolder string, migrationVersion uint) (string, func(), error) { |
Contributor
There was a problem hiding this comment.
Also only tested, never used.
This file contains hidden or 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
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.
https://gesundheitscloud.atlassian.net/browse/HUB-4300
Summary
This PR introduces a versioned migration flow alongside the legacy flow and updates migration documentation/diagrams. The new flow interleaves before -> AutoMigrate(version) -> after for each version, enabling complete, version-by-version migrations.
Background / Problem
Until now,
go-svconly supported a single AutoMigrate pass plus SQL migrations. That made it hard to express a full migration path across multiple versions, especially when a specific version required changes before or after AutoMigrate. The new versioned flow makes this explicit and more intuitive by letting services define migrations per version with before/auto/after steps.Changes
golang-migrate.up.sql).{version}_{name}.before.sqlor{version}_{name}.before.up.sql{version}_{name}.after.sqlor{version}_{name}.after.up.sqlWithMigrationFuncandWithVersionedMigrationFuncerrors out early.Tests Added
.before.sql/.after.sqland.before.up.sql/.after.up.sql(incl. conflict handling).startFromZero, dirty flag, ErrNilVersion handling).User Impact
Services can now opt into version-by-version migrations with explicit before/auto/after steps while legacy users remain unaffected.
Notes
Legacy flow continues to use
.up.sqlfiles withgolang-migrate.FYI (@weese + @LRueckert )
Contrary to what we previously sketched in our call: I kept the legacy branch and the versioned migration branch separate. We originally discussed implementing legacy support by having
WithMigrationFuncsetWithVersionedMigrationFuncvia a wrapper, but we dropped that approach.Rationale: the two flows have different semantics (legacy: AutoMigrate once + tracked
.up.sql; versioned: per-version before/auto/after + version recording). Keeping them separate makes configuration explicit, preserves legacy behavior, and avoids subtle wrapper-induced regressions. We also guard against accidental misconfiguration by erroring if both functions are set.