clintropolis commented on code in PR #13214:
URL: https://github.com/apache/druid/pull/13214#discussion_r992887572
##########
sql/src/test/java/org/apache/druid/sql/calcite/CalciteNestedDataQueryTest.java:
##########
@@ -2003,6 +2032,35 @@ public void testReturningAndSumPathDecimal()
);
}
+ @Test
+ public void testReturningAndSumPathDecimalWithMaths()
+ {
+ testQuery(
Review Comment:
the long test doesn't fail only the decimal does because the sql tests run
in both modes. But, i looked closer to better answer your question which has
caused me to discover another bug, which is that the column inspector that
expressions use to determine things like if they can vectorize and their output
type does not actually have access to other virtual columns, only physical
segments.
This causes the 'can vectorize' check to compute the output type of the
nested field virtual column as 'null' instead of 'STRING', which is what it
would have seen if the virtual column was available, causing it to fail to
vectorize (which is not awesome, but at least doesn't result in an exception).
Since the type is inferred as 'null', the division expression thinks its inputs
are null and double, which is vectorizable as basically all nulls (or zeros in
default value mode), however when it gets to actually running the query a
sanity check to make sure that the query is vectorizable with an inspector
which _does_ have access to the virtual columns sees the input types as
`STRING` and `DOUBLE`, which is not vectorizable, causing the exception.
I'll work on fixing this, thanks for asking :+1:
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
