geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Swapnil Bawaskar <sbawas...@pivotal.io>
Subject Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces
Date Mon, 20 Nov 2017 20:56:09 GMT
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 <jhyde@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 <ctzolov@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 <jhuynh@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 <ctzolov@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/> | ctzolov@pivotal.io |
> >> +31610285517 <+31%206%2010285517>
> >> > <+31%206%2010285517>
> >> >
> >>
> >
> >
> >
> > --
> > Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle
> Software
> > Engineer | Pivotal <http://pivotal.io/> | ctzolov@pivotal.io |
> +31610285517 <+31%206%2010285517>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message