You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I might be misunderstanding here, but I've been running through a few scenarios where I'd like to implement a hybrid migration versioning system before merging to the main development branch. On merge, CI would run goose fix and commit those new sequential-number-versioned migrations.
The problem I've found is, if a developer were to create a date-version-based migration locally and submit a PR for their code, once their code is merged with their migration(s), and the developer pulled master after CI had renamed their date-version-based migration to a sequential-number-based migration, the developers environment is then broken because their date-version-based migration has been renamed and Goose doesn't know how to handle that.
See example below, where after goose fix'ing my already applied date-version-based migration, migrations failed to run as the old date-version-based migration is missing:
2024/06/26 13:56:21 goose run: error: found 1 missing migrations before current version 20240626133012:
version 2: /workspaces/purple-user-translations-api/db/migrations/00002_modify_company.go
I think I'm following the recommended approach under this section of the docs, if not, could anyone advise how to approach this problem? Perhaps its an oversight in Goose?
I'm going to stick with a date-version-based approach for now but would be good to get this working in future if, for example, the migration tracking table was updated to be able to associate the original date-version-based migration name with the new seqential-number-based migration name.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi all,
I might be misunderstanding here, but I've been running through a few scenarios where I'd like to implement a hybrid migration versioning system before merging to the main development branch. On merge, CI would run
goose fix
and commit those new sequential-number-versioned migrations.The problem I've found is, if a developer were to create a date-version-based migration locally and submit a PR for their code, once their code is merged with their migration(s), and the developer pulled master after CI had renamed their date-version-based migration to a sequential-number-based migration, the developers environment is then broken because their date-version-based migration has been renamed and Goose doesn't know how to handle that.
See example below, where after
goose fix
'ing my already applied date-version-based migration, migrations failed to run as the old date-version-based migration is missing:I think I'm following the recommended approach under this section of the docs, if not, could anyone advise how to approach this problem? Perhaps its an oversight in Goose?
I'm going to stick with a date-version-based approach for now but would be good to get this working in future if, for example, the migration tracking table was updated to be able to associate the original date-version-based migration name with the new seqential-number-based migration name.
Thanks!
The text was updated successfully, but these errors were encountered: