Skip to content

API: Fix Identity projection for mismatched transform types#17261

Open
yadavay-amzn wants to merge 1 commit into
apache:mainfrom
yadavay-amzn:fix/15502-identity-projection
Open

API: Fix Identity projection for mismatched transform types#17261
yadavay-amzn wants to merge 1 commit into
apache:mainfrom
yadavay-amzn:fix/15502-identity-projection

Conversation

@yadavay-amzn

Copy link
Copy Markdown
Contributor

This continues #16074, which was auto-closed by the stale bot and can no longer be reopened (GitHub blocks reopening because the branch was force-pushed/recreated). Same fix, rebased onto current main.

What

Identity.projectStrict() currently produces a predicate even when the predicate term is a transform expression rather than a BoundReference, which yields an invalid cross-type predicate during partition projection. This adds a guard so that a non-BoundReference term makes projectStrict() return null, letting the projection framework fall back to alwaysTrue/alwaysFalse. project() delegates to projectStrict(), so both paths are covered.

Why

Fixes #15502 - Identity partition projection returns incorrect results when the source and projected transform types differ.

Tests

Adds a regression test in TestProjection that exercises the mismatched-transform case; it fails on the pre-fix code (producing an invalid ref(...) == ... predicate instead of alwaysTrue) and passes with the fix.

…5502)

Identity.project() and projectStrict() delegate to projectStrict() which
creates an unbound predicate with the literal from the input predicate.
When the predicate term is a transform (e.g. hours(ts) = 490674), the
literal type (integer) does not match the partition field type
(timestamptz), causing a ValidationException when the unbound predicate
is later bound to the partition schema.

Fix: Return null from projectStrict() when the predicate term is not a
BoundReference, indicating the identity transform cannot project
transform-based predicates. This causes the projection to fall back to
alwaysTrue (inclusive) or alwaysFalse (strict), which is correct.
@yadavay-amzn

yadavay-amzn commented Jul 17, 2026

Copy link
Copy Markdown
Contributor Author

@ebyhr this is the rebased continuation of #16074 (which the stale bot closed and GitHub won't let me reopen - the branch was force-pushed/recreated). It's a small fix for Identity projection on mismatched transform types (#15502), now rebased onto current main and green. Would you be willing to take another look when you have a moment?

@uros-b uros-b 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.

Thank you @yadavay-amzn for this well targeted fix, LGTM!

@yadavay-amzn

Copy link
Copy Markdown
Contributor Author

Thanks @uros-b for approving!
requesting @ebyhr to also take a look

Comment on lines +400 to +408
// Regression test for https://github.com/apache/iceberg/issues/15502
// When an identity-partitioned timestamptz field is filtered with hours(), the
// projection must return alwaysTrue (inclusive) or alwaysFalse (strict) because
// the identity transform cannot project a transform-based predicate.
//
// Without the fix, projectStrict() returns an invalid UnboundPredicate with an
// integer literal (490674) for a timestamptz field. This test fails because the
// result is neither alwaysTrue nor alwaysFalse -- it is the invalid predicate
// "ts == 490674" which causes a downstream ValidationException when evaluated.

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.

I think the current comment is too verbose. Suggested replacement:

// Regression test for https://github.com/apache/iceberg/issues/15502.
// Identity transform cannot project a transform-based predicate (e.g., hours(ts)),
// so projection must fall back to alwaysTrue (inclusive) or alwaysFalse (strict).

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ValidationException when filtering identity-partitioned timestamp field using other transforms

3 participants