Hi Tal, I'm sure there are valid reasons that you are using your own SQL parser and not the one provided by Calcite but can you briefly explain why? This is to understand if there are things that we could do to improve Calcite.
I don't have any particular experience for the use case you mentioned but one thing that comes first to my mind is to serialize, send, and deserialize the entire plan [1, 2, 3]. Best, Stamatis [1] https://github.com/apache/calcite/blob/d0180d160120e5d775b000549b7edac30250a353/core/src/test/java/org/apache/calcite/plan/RelWriterTest.java#L491 [2] https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/externalize/RelJsonReader.java [3] https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/externalize/RelJsonWriter.java On Sun, Apr 5, 2020, 11:44 AM Tal Glanzman <[email protected]> wrote: > Hi, > > I'm looking for a some guidance / references on how to approach the > following scenario. > > I have 2 separate software modules > 1. Cpp-Codebase that parses an SQL query and construct a plan > 2. Calcite adapter to my specific domain > > My goal is to provide a server, such that the Cpp-Codebase, as the client, > can construct (in the server) a corresponding plan (of calcite). The client > shouldn't receive the constructed plan back. > > Basically, it's an integration problem, i want to convert NativePlan@Client > to RelNode@Server. > > *I am looking for references based on your experience how would i go about > this. * > > My initial intuition is to provide a gRPC service, with messages that > according to will construct the plan > - the client will convert it's model to the gRPC model > - the server will convert the gRPC model to the RelNode > > This also includes a manual construction of the RelNode which im not sure > how to go about... > > Thanks in advance! > Tal >
