Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces

[Akihiro Kitada]

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   |  Mon-Fri  9:00am to
5:30pm JST  |  1-877-477-2269
[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]



2017-11-21 5:56 GMT+09:00 Swapnil Bawaskar :

> Hi Christian and Julian,
> This indeed sounds very promising.
> Looking at the formidable list of "Powered by Calcite
> " projects, I think we
> should explore embedding Calcite in Geode.
>
> On Thu, Nov 16, 2017 at 2:52 PM Julian Hyde  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 
> > 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  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 

Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces

[Swapnil Bawaskar]

Hi Christian and Julian,
This indeed sounds very promising.
Looking at the formidable list of "Powered by Calcite
" projects, I think we
should explore embedding Calcite in Geode.

On Thu, Nov 16, 2017 at 2:52 PM Julian Hyde  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 
> 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  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 
> >> 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 

Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces

[Julian Hyde]

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  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  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 
>> 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  | Principle
>> Software
>> > Engineer | Pivotal  | ctzo...@pivotal.io |
>> +31610285517
>> > <+31%206%2010285517>
>> >
>>
>
>
>
> --
> Christian Tzolov  | Principle Software
> Engineer | Pivotal  | ctzo...@pivotal.io |+31610285517

Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces

[Christian Tzolov]

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  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 
> 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  | Principle
> Software
> > Engineer | Pivotal  | ctzo...@pivotal.io |
> +31610285517
> > <+31%206%2010285517>
> >
>



-- 
Christian Tzolov  | Principle Software
Engineer | Pivotal  | ctzo...@pivotal.io |+31610285517

Re: [Discussion] SQL+Streaming/JDBC as one of the unified interfaces

[Jason Huynh]

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  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  | Principle Software
> Engineer | Pivotal  | ctzo...@pivotal.io |+31610285517
> <+31%206%2010285517>
>