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> ------------------------------ ------------------------------
