Clearly a bug. Since Calcite (unlike Drill) is strongly typed, it probably should fail validation unless there is a cast to a type that SUM can handle.
Julian > On Sep 11, 2017, at 4:44 AM, Vladimir Sitnikov <[email protected]> > wrote: > > I'm using "ITEM" operator (aka map access), like the following: > select hm.this['@retained'] from java.util.HashMap hm; > > Calcite infers this['@retained'] as "ANY" type. > The SQL works just fine. > > However if I try to use computation, e.g. select sum(this['@retained']) > ..., then evaluation fails. > The statement passes validator and fails in Enumerable compilation as > follows: > /* 1 */ public static class Record2_0 implements java.io.Serializable { > /* 2 */ public Object f0; > ... > /* 35 */ } > ... > /* 80 */ .apply(), new org.apache.calcite.linq4j.function.Function2() { > /* 81 */ public Record2_0 apply(Record2_0 acc, Object in) { > /* 82 */ if (in != null) { > /* 83 */ acc.f1 = true; > /* 84 */ acc.f0 = (Object) (acc.f0 + in); <-- adding > Object+Object > /* 85 */ } > > It does look like a drawback. > > Any ideas if it is a bug or feature? > In case of a bug is it validator or executor related? > > Vladimir
