Hell folks, This is a very interesting discussion to provide additional migration options for users loving SQLFire/GemFire XD.
>1. Would you be interested to have the adapter as part of Geode's code ecosystem? If such a adapter is embedded in GemFire (commercial version of Apache Geode) as a result, some existing SQLFire/GemFire XD users could be interested in it. Because of EOSL of SQLFire/GemFire XD products, current their one of migration paths is SnappyData (like GemFire XD + Apache Spark and etc...) but it's too much for non-Spark users (I.e., users only needing SQL capability for OLTP empowered by in-memory data grid). It seems that Apache Calcite is a simple and handy solution for such users. In terms of SQL capability of SQLFire/GemFire XD products, they are based on Apache Derby. I hope Apache Calcite (based on the modern implementation) is faster than Apache Derby, in terms of query speed. Thanks, regards. -- Akihiro Kitada | Staff Customer Engineer | +81 80 3716 3736 Support.Pivotal.io <http://support.pivotal.io/> | Mon-Fri 9:00am to 5:30pm JST | 1-877-477-2269 [image: support] <https://support.pivotal.io/> [image: twitter] <https://twitter.com/pivotal> [image: linkedin] <https://www.linkedin.com/company/3048967> [image: facebook] <https://www.facebook.com/pivotalsoftware> [image: google plus] <https://plus.google.com/+Pivotal> [image: youtube] <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl> 2017-11-21 5:56 GMT+09:00 Swapnil Bawaskar <sbawas...@pivotal.io>: > 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> > > >
