Well of course Calcite is connected to JDBC. It needs an INTEGER type that other dialects recognize as an INTEGER type. So it uses java.sql.Types.INTEGER, whose value is 4.
In the .NET world you have DataTypeEnum.adInteger, whose value is 3, and maps onto ODBC’s DBTYPE_I4. The concepts are largely the same, but the values are different. You have to do that mapping. IKVM can’t do it, because the .NET concepts don’t exist in the Java code it is translating. > On Oct 18, 2025, at 7:16 PM, Jerome Haltom <[email protected]> wrote: > > IKVM does 100%. But it is not a code translator. Byte code to IL. > > We pass the full JDK test suite, for JDK8 anyways. > > So you can kind of forget I'm using it, and pretend I'm just asking about > Java, but I've got a custom driver framework that isn't JDBC, so I'm trying > to do what Calcites JDBC driver does without JDBC. > > The question is where in Calcite does the JDBC end and the Calcite begin, if > you get my drift. > > Get Outlook for Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Julian Hyde <[email protected]> > Sent: Saturday, October 18, 2025 9:04:56 PM > To: [email protected] <[email protected]> > Subject: Re: Calcite and !JDBC > > It’s no accident that the comment at the top of CalcitePrepareImpl is “Shit > just got real”. It’s the coordinator of the planning process, so needs to > deal with both expression algebra and dynamics (generating a statement id, so > that the statement can hook into resource and lifecycle management). It’s > hard to cut this Gordian knot. > > Can you mock the JDBC bits, or map them onto .NET concepts? (They’re not too > dissimilar… both evolved from ODBC.) > > If I were taking on this project, and using an automated translation tool > like IKVM, I would make a clone of the Calcite Java code and refactor it a > bit. I don’t know IKVM but I suspect that it can do 90% or 99% but struggles > with the last 1%. Once you’ve discovered which refactorings made it work, > you’ve discovered which are the right cuts in the Gordian knot, and can > perhaps contribute those back to Calcite. > > Julian > > >> On Oct 17, 2025, at 9:09 AM, 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. >> >> >
