Thanks for the hint Michael, The problem was in the GeodeUitils#handleStructEntry method. It use to return the results using the original types from the underlaying systems. This works for the column/field types because the schema is inferred from the entity java class but it doesn't for the aggregated results (at lest for some of them) . I made it convert the result in accordance with the expected relDataTypeFields and this solved it. --Chees
On 9 November 2017 at 17:28, Michael Mior <[email protected]> wrote: > Ultimately the result you return from GeodeEnumerator.current needs to have > the correct type. It's hard to follow exactly what's going on with the > reflection that's happening, but you probably need to make some changes to > GeodeUtils.handleJavaObjectEntry. > > -- > Michael Mior > [email protected] > > 2017-11-09 11:25 GMT-05:00 Christian Tzolov <[email protected]>: > > > Regarding > > > if you're pushing down > > > > aggregations, you should just make sure that you convert > > > the result your adapter returns to a Long. (e.g. > > Long.valueOf(count.longValue())) > > > > Where to apply the conversion? Inside the GeodeAggregateRel rule? > > > > Thanks > > > > On 9 November 2017 at 17:21, Christian Tzolov <[email protected]> > wrote: > > > > > Hi Michael, > > > > > > You can find current version in my branch here: https://github.com/ > > > tzolov/calcite/tree/geode-1.3 > > > > > > I still have not added geode to the calcite-test-dataset so reproduce > the > > > problem you need to do this: > > > > > > 1. Download geode-sample-bootstrap-0.0.1-SNAPSHOT.jar from: > > > https://drive.google.com/file/d/0Bw0P8rbcmBaJaGlVZWVEaWE4Tmc > > > It is a single-node, self-contained SpringBoot app that embeds apache > > > geode populates some sample data. > > > Run it like this: > > > java -Xmx128M -Dgemfire.name=server1 -Dgemfire.server.port=40405 > > > -Dgemfire.jmx-manager-port=1199 -Dgemfire.jmx-manager=true > > > -Dgemfire.jmx-manager-start=true -Dgemfire.locators=localhost[10334] > > > -Dgemfire.start-locator=localhost[10334] -Dgemfire.use-cluster- > > configuration=false > > > -jar ./geode-sample-bootstrap-0.0.1-SNAPSHOT.jar > > > > > > 2. Start the sqlline and connect to Geode using the > > > geode/src/test/resources/model-rel2.json model: > > > > > > sqlline> !connect jdbc:calcite:model=/Users/ > ctzolov/Dev/projects/apache- > > > calcite-tzolov/geode/src/test/resources/model-rel2.json admin admin > > > > > > 0: sqlline> SELECT SUM("retailCost") FROM "BookMaster" GROUP BY > > > "retailCost"; > > > > > > +--------+ > > > | EXPR$0 | > > > +--------+ > > > | 59.99 | > > > | 11.99 | > > > | 34.99 | > > > +--------+ > > > > > > 0: sqlline> SELECT COUNT(*) FROM "BookMaster"; > > > > > > java.lang.ClassCastException: java.lang.Integer cannot be cast to > > > java.lang.Long > > > at org.apache.calcite.avatica.util.AbstractCursor$ > LongAccessor.getLong( > > > AbstractCursor.java:550) > > > at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:306) > > > at org.apache.calcite.avatica.AvaticaResultSet.getObject( > > > AvaticaResultSet.java:409) > > > at sqlline.Rows$Row.<init>(Rows.java:157) > > > > > > > > > Cheers, > > > Christian > > > > > > On 9 November 2017 at 16:45, Michael Mior <[email protected]> wrote: > > > > > >> Christian, > > >> > > >> Are you able to share your code for the adapter? This would be helpful > > in > > >> understanding the problem. In short however, if you're pushing down > > >> aggregations, you should just make sure that you convert the result > your > > >> adapter returns to a Long. (e.g. Long.valueOf(count.longValue())) > > >> > > >> -- > > >> Michael Mior > > >> [email protected] > > >> > > >> 2017-11-09 10:41 GMT-05:00 Christian Tzolov <[email protected]>: > > >> > > >> > (Calcite 1.15.0-SNASHOT and Avalitca 1.10.0) > > >> > > > >> > I'm > > >> > workin on an adapter for in-memory NoSql > > >> > data > > >> > system > > >> > . The implementations tries to push down all supported aggregation > > >> > operations, such as AVG, MAX and COUNT. It works for most of them > but > > >> fails > > >> > for COUNT: > > >> > > > >> > > > >> > 0: jdbc:calcite:model= > > >> > ... > > >> > > SELECT COUNT(*) FROM "BookMaster"; > > >> > > > >> > java.lang.ClassCastException: java.lang.Integer cannot be cast to > > >> > java.lang.Long > > >> > at > > >> > org.apache.calcite.avatica.util.AbstractCursor$ > LongAccessor.getLong( > > >> > AbstractCursor.java:550) > > >> > at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:306) > > >> > at > > >> > org.apache.calcite.avatica.AvaticaResultSet.getObject( > > >> > AvaticaResultSet.java:409) > > >> > at sqlline.Rows$Row.<init>(Rows.java:157) > > >> > > > >> > P > > >> > roblem IMO is that the > > >> > COUNT result form the > > >> > underlaying system > > >> > is of type > > >> > Integer while > > >> > C > > >> > alcite expects Long > > >> > (e.g. BIGINT) as > > >> > hardcoded in SqlCountAggFunction > > >> > .java. > > >> > > > >> > I can't alter the SqlCountAggFunction so I wonder what is the > right > > >> place > > >> > in Calcite to implement/configure this type conversion? > > >> > > > >> > This issue looks very similar ( > > >> > https://issues.apache.org/jira/browse/CALCITE-665) but i am not > > sure i > > >> > completely understand the resolution? > > >> > > > >> > Thanks, > > >> > Christian > > >> > > > >> > > > > > > > > > > > > -- > > > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle > > Software > > > Engineer | Pivotal <http://pivotal.io/> | [email protected] | > > +31610285517 > > > > > > > > > > > -- > > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle > Software > > Engineer | Pivotal <http://pivotal.io/> | [email protected] | > +31610285517 > > > -- Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle Software Engineer | Pivotal <http://pivotal.io/> | [email protected] |+31610285517
