To plan over .NET data structures, you might be able to develop a schema adapter (https://calcite.apache.org/docs/adapter.html) that wraps those .NET System.Data structures (Calcite -> .NET to Calcite schema adapter -> .NET System.Data), which should be easier than trying to develop a complete JDBC wrapper over .NET System.Data and then use it through the existing JDBC schema adapter (Calcite -> JDBC schema adapter -> .NET to JDBC schema adapter -> .NET System.Data). For an example you can look at the CSV schema adapter ( https://github.com/apache/calcite/tree/main/example/csv/src/main/java/org/apache/calcite/adapter/csv ).
That's on the backend. The frontend to Calcite would still be JDBC, but maybe https://github.com/chequer-io/JDBC.NET could help you wrap it into .NET APIs? Damjan On Sat, Oct 18, 2025 at 12:14 PM Jerome Haltom <[email protected]> wrote: > Unfortunately that is completely insufficient for my needs. I'm using > Calcite to plan over .NET data structures. > > Get Outlook for Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Istvan Toth <[email protected]> > Sent: Saturday, October 18, 2025 2:22:12 AM > To: [email protected] <[email protected]> > Subject: Re: Calcite and !JDBC > > The easiest way to do something like this is with Avatica. > > Avatica server exposes and proxies the JDBC operations over a simple > protobuf RPC layer. > The raw protobuf client can be trivially generated, and you can build the > .Net API on top of that. > > For reference, the phoenix python connector does the same for the Python DB > API: > https://github.com/apache/phoenix-queryserver/tree/master/python-phoenixdb > > Here is an earler version of it without the phoenix-specic type mapping > code: > https://github.com/lalinsky/python-phoenixdb > > There is also an existing .NET client, but that does not include the > mapping between the Avatica protocol and the native DB API. > https://github.com/Azure/hdinsight-phoenix-sharp > > Istvan > > > On Fri, Oct 17, 2025 at 6:10 PM Jerome Haltom <[email protected]> > wrote: > > > Hello. > > > > I am doing an interesting project (or so I think) using Calcite. I am > > attempting to write a .NET library that makes use of Calcite. The goal > > being to expose the Calcite operations one can normally do under JDBC in > a > > nice .NET-like API surface using System.Data. So, a .NET class, > > Apache.Calcite.Data.CalciteConnection, which implements the .NET > > driver/connection model, but ultimately does the same thing the Calcite > > JDBC driver does. A nice clean .NET-like API surface that uses Calcite > > under the covers. I am doing this with IKVM (which is a JVM > > "implementation" that converts Java bytecode to .NET IL). > > > > I have no problem fully using all the Calcite classes this way. Including > > the JDBC driver, etc. Everything works perfectly fine. So, my question is > > not about this translation layer, or this JVM implementation, or anything > > like that. I only mention it to provide context to my question. > > > > My question is about how 'deep' into the core Calcite code the JDBC stuff > > extends. > > > > I started this effort out by figuring I would mostly just need to rewrite > > a more appropriate version of org.apache.calcite.jdbc, that ultimately > > surfaced a .NET API but used all the same Calcite internals. But the > more I > > dig into that, the more I find a few JDBC-isms that have snuck outside > that > > package. For instance, org.apache.calcite.jdbc.CalciteScema is a big > class. > > Doing quite a bit of work. And it's referenced by > > org.apache.calcite.prepare. And it's also accessed by the > > SqlSpatialTypeOperatorTable. And a few things in sql.validate. And some > > stuff in calcite.schema.impl.ViewTable, materialize, etc. > > > > Basically, JDBC extends deeper into Calcite than I had expected. So, I'm > > no longer just confronted with writing a new Connection-like > > implementation, but with new implementations of a number of other classes > > that seem pretty unrelated to JDBC itself. > > > > So, then I think, okay. I may abandon that plan and instead preserve and > > not rewrite a class like CalciteSchema. But use the existing > > jdbc.CalciteSchema in my new CalciteConnection implementation. The > > namespaces/packages won't be as clear to users: they'll be creating > > jdbc.CalciteSchemas and adding them to > > Apache.Cacite.Data.CalciteConnections. Bit funny looking. But should > work. > > > > So, how much of jdbc.* can I preserve, and how much is actually tied to > > JDBC? CalciteSchema seems pretty clear. But, CalcitePrepare does not! > > CalcitePrepare has a few things in it, like CalciteSignature, which > extends > > an Avatica class, Meta.Signature, and expects a list of > AvaticaParameters. > > And this is very much JDBC-tied. But I need CalcitePrepare because of > > materialize/Lattice and all that. > > > > So, it looks like bunch of Core stuff is tied into CalcitePrepare. But I > > can't make use it since it relies on having a bunch of Avatica JDBC > > specific stuff exposed. Which a non-JDBC access method wouldn't have. > > > > Any recommendations here? Ignore my .NET related context if you want, and > > pretend I'm writing a driver for some other driver framework that just > has > > no support for JDBC-like stuff. > > > > > > > > -- > *István Tóth* | Sr. Staff Software Engineer > *Email*: [email protected] > cloudera.com <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera > on LinkedIn] <https://www.linkedin.com/company/cloudera> > ------------------------------ > ------------------------------ >
