-
Notifications
You must be signed in to change notification settings - Fork 254
-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Statement-level granularity: Infinitely pending migration #2455
Comments
ruslic19
added a commit
to ruslic19/atlas
that referenced
this issue
Jan 17, 2024
The reason for this is that users are required to edit existing migration files to resolve partial failure issues. Without keeping total in sync, such migration would be considered still pending, because total != applied. Issue: ariga#2455
ruslic19
added a commit
to ruslic19/atlas
that referenced
this issue
Jan 17, 2024
The reason for this is that users are required to edit existing migration files to resolve partial failure issues. Without keeping total in sync, such migration would be considered still pending, because total != applied. Issue: ariga#2455
Suggested Fix: #2456 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As described in atlas documentation here, migrations can partially fail and in provided there case in order to fix it, we add one more statement to our migration and then rerun it again.
Expected:
There is
atlas migrate status
which returns amount of pending migrations and when let's say our last migration partially fails, status command returns uspending: 1
which is supposed to become0
when we will successfully fix and execute our partially failed migration.Actual:
When our migration partially fails, we get
pending: 1
as expected, but then when we fix it and execute it again, even if it executes successfully,pending
remains to be1
, because of this, we can now execute our migrations multiple times and it never tells us that there is no migrations to execute anymore.Steps to reproduce:
In general you can even use guide from statement level granularity itself or you can do it like this
users
table schema with nullable nameusers
table with name beingnull
users
table schema to have nameNOT NULL
null
valuespending
atlas_schema_revisions
table now hastotal = 1
andapplied = 2
and this is the cause of the issueReason:
As I understand it is related to the fact that we determine if migration is pending by comparing applied statements to the total statements in a given migration. Migration is considered to be complete only if amount of applied statements strictly equals to amount of total statements in the migration. For example, here in the code.
Whereas, in this case, when we update our migration to add new statement and execute it now successfully, row in the table
atlas_schema_revisions
responsible for this migration now containstotal=value_before_we_added_new_statement
andapplied=all_executed_statements_including_new_one
, so it results in something like this:total=1
applied=2
.Of course, we could just change strict equality to
>=
but this would cause issues in case when fixed migration partially fails again, so instead, when we execute migration, we should also updatetotal
to keep it up to date. Currently during apply migration process, when we find existing revision, we don't update it's total, butonly executed at
andoperation version
.Suggested Fix: #2456
It is possible that this fix can cause some unexpected side effects, because it was tested only using use case described in this issue
The text was updated successfully, but these errors were encountered: