Hi Jerome, As you already observed JDBC concepts are not fully isolated in a single package so if you want to mimic the capabilities of jdbc:calcite you will probably have to touch/use many classes in core.
My first reaction when I saw the message was the same as what Damjan proposed. If you want to do everything that a JDBC connection does then it would be less work and probably more general to build a NET wrapper over JDBC. In some cases, it is indeed useful to have new APIs/drivers for interacting with Calcite and I've done it for a few projects in the past. The main difference though is that I was not aiming to replicate what jdbc:connection offers but rather define APIs for specific DBMS engines. Depending on exactly what the engine needs the difficulty and the number of classes that you need to touch varies. Best, Stamatis On Sun, Oct 19, 2025 at 2:43 PM Jerome Haltom <[email protected]> wrote: > > https://github.com/ikvmnet/calcite-dotnet/tree/main/src/Apache.Calcite.Adapter.Ado > is the ADO backend I have working. > > This repository is early days however. That one project works, but the rest > are in progress. > > Get Outlook for Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Mark <[email protected]> > Sent: Sunday, October 19, 2025 4:36:12 AM > To: [email protected] <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: Calcite and !JDBC > > Hi Jerome, > > Are you able to share your IKVM-based Calcite query engine repo? Had tried > using IKVM sometime ago but wasn’t able to get a workable solution for > querying custom data structures. > > Dotnet suffers from a dearth of efficient query engines. I found baby Kusto > to be very accessible, and there is Grafana language server support for KQL, > but it has no query optimizer. However KQL is very much locked down and > effectively prevents contributing user defined functions, which is a bit of a > blocker for me. Top tier Calcite support for dotnet, in any shape or form, > would be amazing. > > -Mark > > > On 19 Oct 2025, at 15:04, Jerome Haltom <[email protected]> wrote: > > > > The backend is already finished. That was quite easy. Did not wrap JDBC, > > but did model my code on it > > > > https://github.com/ikvmnet/calcite-dotnet/tree/main/src/Apache.Calcite.Adapter.Ado > > > > Had to do some with on the dialect stuff though, since. Net DB driver's > > have no Metadata stuff. > > > > The front end is where in having problems, since I can't figure out what > > I'm going to have to replace. > > > > Get Outlook for Android<https://aka.ms/AAb9ysg> > > ________________________________ > > From: Damjan Jovanovic <[email protected]> > > Sent: Sunday, October 19, 2025 1:02:29 AM > > To: [email protected] <[email protected]> > > Subject: Re: Calcite and !JDBC > > > > 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> > >> ------------------------------ > >> ------------------------------ > >>
