Re: [DISCUSS] The state of the project - 2017

Michael, I think the ownership thinking is a really good idea. Things like trait behaviors, volcano, types, hep, decorrelation, parsing, sql-to-rel, materialized views are all good chunks that could be owned by someone. (in addition to avatica and each of the connectors). On Wed, Nov 8, 2017 at

Re: COUNT returns Integer while Calcite expects Long

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

Re: COUNT returns Integer while Calcite expects Long

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 mm...@apache.org

Re: COUNT returns Integer while Calcite expects Long

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

Re: COUNT returns Integer while Calcite expects Long

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:

Re: COUNT returns Integer while Calcite expects Long

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())) --

COUNT returns Integer while Calcite expects Long

​(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= ​... >

Calcite-Master - Build # 139 - Still Failing

The Apache Jenkins build system has built Calcite-Master (build #139) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/139/ to view the results.

Recycling Planner objects

I am going to use Calcite Planner inside my DBMS. I would like to understand which objects can be reused and which objects are treated in a dynamic fashion. Planner object, is this cachable ? I see i is not stateless. Is it better to alwayes create a new instance or could it be reclycled ? Table

Re: Volcano planner

The example from Luis works like a charm. I have some questions,I will start separate threads Thank you Enrico 2017-11-08 21:51 GMT+01:00 Enrico Olivelli : > Luis thank you, > my case is the second one. I want to use Calcite planner internally on a > database system. I will