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
TruncateTransform.satisfies_order_of reads self.source_type (and other.source_type) when the two transforms are not equal, but TruncateTransform.__init__ only sets _width and never sets _source_type. Comparing two truncate transforms of different widths therefore raises AttributeError: 'TruncateTransform' object has no attribute '_source_type' instead of returning a boolean, because same-width comparisons only work by taking the early self == other return. Two truncate transforms are ordered by width, so the comparison can be decided from the widths alone.
Are these changes tested?
Yes. Added test_truncate_satisfies_order_of_different_widths and confirmed the existing transform tests still pass (pytest tests/test_transforms.py -k "truncate or satisfies_order"). The two test_truncate_pyarrow_transforms cases that fail locally require the optional pyiceberg-core extra and are unrelated to this change.
Good question. The _source_type PrivateAttr on TruncateTransform is never assigned anywhere in the codebase, so self.source_type raises AttributeError on any non-equal comparison, which is the crash this PR fixes (#3680). That means the previous StringType branch never actually ran for a bare TruncateTransform(n) either.
For the widening concern: satisfies_order_of is only meaningful when both transforms are bound to the same source field (same sort key), so they already share a type family by construction; a truncate transform carries no independent source type to cross-compare. This also matches the sibling transforms in this file, e.g. the time transforms compare purely on granularity and BucketTransform on num_buckets, without re-checking the source type. The added test asserts a non-truncate (BucketTransform) returns False, so cross-transform mixing is still rejected. Happy to add an explicit same-family guard if you'd prefer it spelled out.
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
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.
Closes #3680
Rationale for this change
TruncateTransform.satisfies_order_ofreadsself.source_type(andother.source_type) when the two transforms are not equal, butTruncateTransform.__init__only sets_widthand never sets_source_type. Comparing two truncate transforms of different widths therefore raisesAttributeError: 'TruncateTransform' object has no attribute '_source_type'instead of returning a boolean, because same-width comparisons only work by taking the earlyself == otherreturn. Two truncate transforms are ordered by width, so the comparison can be decided from the widths alone.Are these changes tested?
Yes. Added
test_truncate_satisfies_order_of_different_widthsand confirmed the existing transform tests still pass (pytest tests/test_transforms.py -k "truncate or satisfies_order"). The twotest_truncate_pyarrow_transformscases that fail locally require the optionalpyiceberg-coreextra and are unrelated to this change.Are there any user-facing changes?
No.