How to write code if the intent is to land it in Calcite eventually?

[Gavin Ray <ra...@gmail.com>]

Stamatis made a remark during the meetup about integrating the GraphQL
library as a module in core.
Something like GqlToRelConverter, similar to SqlToRelConverter.

I hadn't thought of this, it's a brilliant idea.
I would like to shift my development into practices that could eventually
be accepted upstream.

Is it correct to assume that this means I'll need to swap Kotlin for Java?
Are there any organizational best-practices, conventions or other things to
keep in mind?

If I must use Java, can I use JDK17 to take advantage of things like
records, sealed types and "switch" pattern matching?

Thank you =)

Re: How to write code if the intent is to land it in Calcite eventually?

[Stamatis Zampetakis <za...@gmail.com>]

I also had a separate module in mind when I made the comment during the
meetup.

Although, I don't want to force people to rewrite their code in another
language in order to be accepted, the truth is that using Java 8 will be
the easiest way to get this in.
I think we are using Java 8 in the biggest part of the project so it might
be better to stick to it for the moment. If we want to jump to a bigger
version I guess this will be a discussion concerning the entire project.
Java remains more popular compared to Kotlin so it will be also easier to
find reviewers to get this in and maintain it in the near future.

Best,
Stamatis


On Fri, Jan 21, 2022 at 1:43 AM Gavin Ray <ra...@gmail.com> wrote:

> Got it, and about the standalone module, yeah absolutely. That makes a lot
> of sense.
> In that case, it would be an additional dependency you'd add, like
> "calcite-csv" and could live alone as a sub-project right?
>
> I will take inspiration from the way that the "piglet" adapter is written
> and try to follow those general conventions, thank you!
>
> On Thu, Jan 20, 2022 at 7:03 PM Julian Hyde <jh...@gmail.com>
> wrote:
>
> > There is one other front-end language (besides SQL) in Calcite: the
> > ‘piglet' module implements Pig Latin (which is the language spoken by
> > Apache Pig). I think the other languages, such as GraphQL, should each be
> > their own module.
> >
> > Calcite has many adapters (i.e. back-ends), and one-module-per-adapter
> has
> > been working well.
> >
> > I’m not going to express an opinion about Kotlin vs Java 17 vs Java 8.
> >
> >
> > > On Jan 20, 2022, at 12:25 PM, Gavin Ray <ra...@gmail.com> wrote:
> > >
> > > Stamatis made a remark during the meetup about integrating the GraphQL
> > > library as a module in core.
> > > Something like GqlToRelConverter, similar to SqlToRelConverter.
> > >
> > > I hadn't thought of this, it's a brilliant idea.
> > > I would like to shift my development into practices that could
> eventually
> > > be accepted upstream.
> > >
> > > Is it correct to assume that this means I'll need to swap Kotlin for
> > Java?
> > > Are there any organizational best-practices, conventions or other
> things
> > to
> > > keep in mind?
> > >
> > > If I must use Java, can I use JDK17 to take advantage of things like
> > > records, sealed types and "switch" pattern matching?
> > >
> > > Thank you =)
> >
> >
>

Re: How to write code if the intent is to land it in Calcite eventually?

[Gavin Ray <ra...@gmail.com>]

Got it, and about the standalone module, yeah absolutely. That makes a lot
of sense.
In that case, it would be an additional dependency you'd add, like
"calcite-csv" and could live alone as a sub-project right?

I will take inspiration from the way that the "piglet" adapter is written
and try to follow those general conventions, thank you!

On Thu, Jan 20, 2022 at 7:03 PM Julian Hyde <jh...@gmail.com> wrote:

> There is one other front-end language (besides SQL) in Calcite: the
> ‘piglet' module implements Pig Latin (which is the language spoken by
> Apache Pig). I think the other languages, such as GraphQL, should each be
> their own module.
>
> Calcite has many adapters (i.e. back-ends), and one-module-per-adapter has
> been working well.
>
> I’m not going to express an opinion about Kotlin vs Java 17 vs Java 8.
>
>
> > On Jan 20, 2022, at 12:25 PM, Gavin Ray <ra...@gmail.com> wrote:
> >
> > Stamatis made a remark during the meetup about integrating the GraphQL
> > library as a module in core.
> > Something like GqlToRelConverter, similar to SqlToRelConverter.
> >
> > I hadn't thought of this, it's a brilliant idea.
> > I would like to shift my development into practices that could eventually
> > be accepted upstream.
> >
> > Is it correct to assume that this means I'll need to swap Kotlin for
> Java?
> > Are there any organizational best-practices, conventions or other things
> to
> > keep in mind?
> >
> > If I must use Java, can I use JDK17 to take advantage of things like
> > records, sealed types and "switch" pattern matching?
> >
> > Thank you =)
>
>

Re: How to write code if the intent is to land it in Calcite eventually?

[Julian Hyde <jh...@gmail.com>]

There is one other front-end language (besides SQL) in Calcite: the ‘piglet' module implements Pig Latin (which is the language spoken by Apache Pig). I think the other languages, such as GraphQL, should each be their own module.

Calcite has many adapters (i.e. back-ends), and one-module-per-adapter has been working well.  

I’m not going to express an opinion about Kotlin vs Java 17 vs Java 8.


> On Jan 20, 2022, at 12:25 PM, Gavin Ray <ra...@gmail.com> wrote:
> 
> Stamatis made a remark during the meetup about integrating the GraphQL
> library as a module in core.
> Something like GqlToRelConverter, similar to SqlToRelConverter.
> 
> I hadn't thought of this, it's a brilliant idea.
> I would like to shift my development into practices that could eventually
> be accepted upstream.
> 
> Is it correct to assume that this means I'll need to swap Kotlin for Java?
> Are there any organizational best-practices, conventions or other things to
> keep in mind?
> 
> If I must use Java, can I use JDK17 to take advantage of things like
> records, sealed types and "switch" pattern matching?
> 
> Thank you =)