Hi Christian and Julian, This indeed sounds very promising. Looking at the formidable list of "Powered by Calcite <http://calcite.apache.org/docs/powered_by.html>" projects, I think we should explore embedding Calcite in Geode.
On Thu, Nov 16, 2017 at 2:52 PM Julian Hyde <jh...@apache.org> wrote: > I'm Julian Hyde, original developer of Calcite and a current PMC member. > > I'd love to see Calcite-Geode integration and so I'm delighted with > the work Christian has been doing. Whenever someone builds an adapter > for a particular data store X, the question comes up whether it should > live in X or become an adapter in Calcite. Generally I prefer the > former. I think Geode would benefit by having a built-in SQL interface > and ODBC/JDBC server, and Calcite embeds quite easily to make that > happen. (You just need a couple of jars from maven, and implement some > SPIs to provide metadata; no extra data on disk.) > > If you don't want that, I think our community would be happy to accept > Christian's code as a Geode adapter in Calcite. Geode would be able to > include that adapter later, albeit with a small added complication of > version differences. > > But if there are particular concerns, or reasons why you do not want > SQL support in Geode, now would be a good time to discuss. > > Julian > > > On Thu, Nov 16, 2017 at 12:22 PM, Christian Tzolov <ctzo...@pivotal.io> > wrote: > > 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> > >> > <+31%206%2010285517> > >> > > >> > > > > > > > > -- > > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle > Software > > Engineer | Pivotal <http://pivotal.io/> | ctzo...@pivotal.io | > +31610285517 <+31%206%2010285517> >
