Thanks Julian for the inputs. >Regarding Object[]. I think that is the type of a *row* (due to the >JavaRowFormat.ARRAY in [1]) not the type of a particular column.
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/PhysTypeImpl.java#L75 >From the code it appears to add the type of the individual columns of the row >into “fieldClasses” so its not clear as to why should “Object[]” be added as >the type when the field type does not directly map to a SQL type. If it was >Object instead of Object[], the generated code would work. If you think it >makes sense, I will submit a patch. Thanks, Arun On 12/27/16, 12:47 PM, "Julian Hyde" <[email protected]> wrote: >The main thing it that the UD(A)F framework can deduce the SQL type of the >parameters and return value of the function. If a function returns Number, >should the SQL type be DECIMAL(p, s), or INTEGER, or BIGINT, or DOUBLE? None >of these options is perfect. If there isn’t an obvious winner, I don’t know >whether we should allow Number. > >Maybe we should add an annotation, similar to Parameter[5], that allows you to >specify the SQL return type of a UDF. In this case, a Java function could >return, say, a SQL BIGINT even if its return type was Object, Number or String. > >Regarding Object[]. I think that is the type of a *row* (due to the >JavaRowFormat.ARRAY in [1]) not the type of a particular column. There have >been bugs due to inconsistencies — Calcite sometimes uses an Object to >represent a single-column row, and sometimes uses an Object[]. Maybe you’re >running into a bug of that kind. > >Julian > >[5] >https://calcite.apache.org/apidocs/org/apache/calcite/linq4j/function/Parameter.html > ><https://calcite.apache.org/apidocs/org/apache/calcite/linq4j/function/Parameter.html> > >> On Dec 26, 2016, at 10:03 PM, Arun Iyer <[email protected]> wrote: >> >> We have a UDAF that returns “Number” as the result type. We use >> RexToLixTranslator to generate java code [1]. In the generated code, the >> value of the field with Number type is cast to Object[] and the compilation >> fails. >> >> When I trace the flow, I see that in PhysTypeImpl the field classes are >> determined via javaRowClass method [2]. The type for the Number field turns >> out to be “BasicSqlType(Other)” and the javaRowClass [3] returns a >> “Object[]”. Somewhere down the line the field value is then cast to >> “Object[]” in the generate code [4]. >> >> Just wondering why Object[] is returned (should unknown fields be mapped to >> Object instead?). Also is it possible to write UDAFs that return super types >> like Number (so that it can work for any sub type) but the return type does >> not directly map to SQL types? >> >> Thanks, >> Arun >> >> [1] >> https://github.com/apache/storm/blob/master/external/sql/storm-sql-core/src/jvm/org/apache/storm/sql/compiler/RexNodeToBlockStatementCompiler.java#L73 >> [2] >> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/PhysTypeImpl.java#L75 >> [3] >> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumUtils.java#L96 >> [4] >> https://gist.github.com/arunmahadevan/35809494467d5636e31c0031f81d9aa7#file-test-java-L149 >> >> >
