IIUC in #2 Beam SQL would live on the other side of a JDBC boundary from any use of it (including the BeamSQL transform). I'm a bit worried we'll have a problem plumbing all the info we need, either now or later, especially if we make funky extensions to support our version of SQL.
Kenn On Wed, May 16, 2018 at 10:08 AM Andrew Pilloud <[email protected]> wrote: > I'm currently adding JDBC support to Beam SQL! Unfortunately Calcite has > two distinct entry points, one for JDBC and one for everything else (see > CALCITE-1525). Eventually that will change, but I'd like to avoid having > two versions of Beam SQL until Calcite converges on a single path for > parsing SQL. Here are the options I am looking at: > > 1. Make JDBC the source of truth for Calcite config and state. Generate a > FrameworkConfig based on the JDBC connection and continue to use the > non-JDBC interface to Calcite. This option comes with the risk that the two > paths into Calcite will diverge (as there is a bunch of code copied from > Calcite to generate the config), but is the easiest to implement and > understand. > > 2. Make JDBC the only path into Calcite. Use prepareStatement and unwrap > to extract a BeamRelNode out of the JDBC interface. This eliminates a > significant amount of code in Beam, but the unwrap path is a little > convoluted. > > Both options leave the user facing non-JDBC interface to Beam SQL > unchanged, these changes are internal. > > Andrew >
