Skip to content

fix: use transform equality for partition compatibility#1314

Open
fallintoplace wants to merge 2 commits into
apache:mainfrom
fallintoplace:fix/partition-spec-transform-equals
Open

fix: use transform equality for partition compatibility#1314
fallintoplace wants to merge 2 commits into
apache:mainfrom
fallintoplace:fix/partition-spec-transform-equals

Conversation

@fallintoplace

Copy link
Copy Markdown
Contributor

Summary

  • compare partition spec transforms with Transform.Equals in CompatibleWith
  • add regression coverage for non-comparable transform implementations

Why

PartitionField.Equals already delegates transform comparison to Transform.Equals, but PartitionSpec.CompatibleWith compared transform interfaces directly. That can panic for non-comparable transform implementations and also bypass transform-specific equality semantics.

Testing

  • go test . -run '^TestPartitionSpecCompatibleWithUsesTransformEquals$' -count=1\n- go test . -count=1\n- go run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.11.4 run --timeout=10m .\n- git diff --check

@fallintoplace fallintoplace requested a review from zeroshade as a code owner June 24, 2026 21:36

@zeroshade zeroshade left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Switching CompatibleWith from interface identity to Transform.Equals is correct, aligns with PartitionField.Equals, and removes the panic risk on non-comparable transforms. One optional coverage nit inline.

Comment thread partitions_test.go
assert.Equal(t, 1002, spec3.LastAssignedFieldID())
}

func TestPartitionSpecCompatibleWithUsesTransformEquals(t *testing.T) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this nicely pins the non-comparable custom-transform path. It'd be worth also asserting the built-in parameterized cases directly at the CompatibleWith level - e.g. bucket[16] vs bucket[32] and truncate[4] vs truncate[8] should be incompatible, while identical transforms stay compatible. They work today via the built-in Equals impls, but a couple of table-driven cases here would guard against regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants