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.
