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 <[email protected]> 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 <[email protected]> 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 =) > >
