[
https://issues.apache.org/jira/browse/CALCITE-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881452#comment-15881452
]
Julian Hyde commented on CALCITE-1601:
--------------------------------------
[~gian], OK, it seems that we have several problems. I confess the logic was a
bit ad hoc (i.e. tests are required to find all the bugs) but I thought I made
it a bit more robust. Maybe it's the '<>' on year; we the algorithm relies on
having a finite set of years to work on before it starts chopping the range
into months and days. Can you please log another bug, and include any and all
Druid test cases that fail when this rule is enabled. Then we can cover them
all in one fell swoop.
> DateRangeRules loses OR filters
> -------------------------------
>
> Key: CALCITE-1601
> URL: https://issues.apache.org/jira/browse/CALCITE-1601
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.11.0
> Reporter: Gian Merlino
> Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> I'm not sure why, but DateRangeRules can lose some filters. For example in
> this query:
> {code}
> SELECT COUNT(*) FROM druid.foo WHERE EXTRACT(YEAR FROM __time) = 2000 AND
> EXTRACT(MONTH FROM __time) IN (2, 3, 5)
> {code}
> The filter gets resolved to __time >= 2000-02-01 and __time < 2000-03-01,
> losing the months "3" and "5". Removing DateRangeRules.FILTER_INSTANCE from
> the planner's rule set stops this from happening.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
