Druid OR filters should not discard matching timestamp ranges

[bvolpato]

Jira Link

Pending issue creation and linkage. This PR is a draft.

Changes Proposed

Druid interval extraction currently ignores OR branches it cannot represent as timestamp intervals. The filter rule then treats the remaining partial intervals as the complete condition and removes the filter, excluding valid rows.

Abort interval extraction if any OR branch is unrepresentable. This lets the existing filter path retain the full predicate. Add regressions for both operand orders, an empty-range branch, and planner behavior that preserves the original intervals and filter.

Reproduction

For a Druid table whose time column is timestamp, this predicate must retain a row dated 2021-01-15:

"timestamp" < TIMESTAMP '2020-01-01 00:00:00'
OR EXTRACT(DAY FROM "timestamp") = 15

The affected plan restricts intervals to dates before 2020 and drops the filter.

./gradlew :druid:test --tests 'org.apache.calcite.test.DruidDateRangeRulesTest' --tests 'org.apache.calcite.adapter.druid.DruidQueryFilterTest'

Validation

• The mixed-OR utility and planner regressions fail against the baseline.
• Direct JUnit execution against the compiled fix passes both complete changed classes: 12 tests, no failures or skips, with assertions enabled.
• ./gradlew autostyleApply and git diff --check pass.
• Focused runs used freshly compiled changed classes with cached supporting artifacts. Native Gradle test-class compilation on pristine main was blocked by java.io.IOException: No space left on device; the full Gradle build has not been validated locally.

Downsides

Mixed OR predicates may scan a wider interval and rely on Druid filtering. Narrowing the interval safely requires accounting for every disjunct.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud