We implemented support for `SET SCHEMA` by subclassing `ServerDdlExecutor`, and calling (in our case) `AvaticaConnection.setSchema(schema)` does indeed work.
However, we've also encountered some JDBC-based applications that will set the explicitly set an incorrect default schema via the connection properties (e.g. they pick the first schema from the catalog) and which lack clear ways to change that behavior--other than by first calling `SET SCHEMA`. It would be a good thing to include out-of-the-box. On 3/15/22, 5:11 PM, "Julian Hyde" <[email protected]> wrote: WARNING: This email originated from outside of GE. Please validate the sender's email address before clicking on links or attachments as they may not be safe. An ancestor project of Calcite, Eigenbase (aka Farrago) used to have a SET SCHEMA command. It would be nice if we added that back. (Maybe only in the “server” module, since in “core” the connections are stateless.) I’m a bit surprised that "CalciteConnection.setSchema(String)" doesn’t work. Put a breakpoint in the constructor of CalciteCatalogReader and see what is the value of schemaPaths. That is effectively the default schema for purposes of validating SQL statements. Julian > On Mar 15, 2022, at 11:49 AM, Gavin Ray <[email protected]> wrote: > > I have a scenario in which I have a rootSchema that holds multiple > datasource schemas > There's a tool I'd like to integrate it with, but it can't handle (catalog > -> schema -> schema) structure > > I figured an easy way around this would be to iterate the names of the > datasource schemas, and then > and then make a clone of the current CalciteConnection with the > defaultSchema set to <db name> > > I can't seem to figure out how to do this, though. > > Calling .setSchema() doesn't seem to work (probably no impact on the JDBC > metadata) > and if I create a new connection with the "schema" property set, then it's > a fresh/empty Calcite source. > > Is there any way to do this? Or some craft hack? > > Thank you =)
