Hi Jason , Thanks for the comments!
Regarding the talk, i'm not completely sure but i believe that as a part of the S1P conference the sessions will be recorded. >> Also for question 1. Would you be interested to have the adapter as part of Geode's code ecosystem? > Do you mean to create a module in Geode for this adapter? Would it make sense to add a Geode module to Calcite? Were you wanting a tighter integration (beyond an adapter) with Calcite within Geode? Currently the adapter is implemented as a pure Geode client using only the public Geode API/OQL. There are no dependencies from Geode to the adapter! 1. If the adapter became one of Calcite project adapter ( https://calcite.apache.org/docs/adapter.html) it will benefit from being up to date with latest Calcite developments. But IMO this might not the most important driving force for evolving the adapter. 2. If it became an "extension" project/module under Geode's project umbrella it will stay closer to it potential users and will evolve with their needs. Hopefully it may attract more contributors if found useful. Personally I would be interested to explore further the approach and figure out what are its strengths and weaknesses. - Cheers, Christian On 13 November 2017 at 19:46, Jason Huynh <jhu...@pivotal.io> wrote: > Hi Christian, > > I don't know much about Calcite and haven't had a chance to try out your > adapter yet but it sounds like a neat idea. Will your talk be recorded and > available after the Summit? > > Also for question 1. Would you be interested to have the adapter as part of > Geode's code ecosystem? > Do you mean to create a module in Geode for this adapter? Would it make > sense to add a Geode module to Calcite? Were you wanting a tighter > integration (beyond an adapter) with Calcite within Geode? > > -Jason > > On Fri, Nov 10, 2017 at 3:49 AM Christian Tzolov <ctzo...@pivotal.io> > wrote: > > > Hi, > > > > I've been working lately on Apache Calcite SQL/JDBC adapter for Apache > > Geode [1]. > > > > Adapter's current implementation act as a plain Geode client (using the > > public API/OQL interfaces) trying to push down to Geode OQL as many > > relational expressions as it can. Relational expressions not supported by > > OQL are executed by the adapter itself. > > > > While this approach has its advantages and disadvantages, which I will > try > > to address at my Geode Summit talk [2] I would like to ask two question: > > > > 1. Would you be interested to have the adapter as part of Geode's code > > ecosystem? > > > > 2. I am aware (an experienced it myself) the SQLFire story. But given > that > > OQL features are expanding (aggregations are are already supported) and > > that tools like Calcite offer proper logical/physical (cost based) planer > > and SQL extensions such as SQL streaming, would it be useful to discuss > > what novel approaches for using SQL/JDBC with Geode are possible? > > > > (Julian Hyde - founder of Calcite - is in cc) > > > > Cheers, > > Christian > > > > [1] https://github.com/tzolov/calcite/tree/geode-1.3 > > [2] > > > > https://springoneplatform.io/sessions/enable-sql-jdbc- > access-to-apache-geode-gemfire-using-apache-calcite > > > > > > -- > > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle > Software > > Engineer | Pivotal <http://pivotal.io/> | ctzo...@pivotal.io | > +31610285517 > > <+31%206%2010285517> > > > -- Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle Software Engineer | Pivotal <http://pivotal.io/> | ctzo...@pivotal.io |+31610285517
