Good idea. Change “scan(String tableName)" to “scan(String… tableNames)”, and also add “scan(Iterable<String> tableNames)” for people who happen to have lists, not arrays.
Note that the list may be fully-qualified but doesn’t have to be. It could be a table within the current database + schema, or schema.table within the current database. I believe that RelOptSchema.getTableForMember will do that. The comment “names.length is only greater than 1 for queries originating from JDBC” relates to the time when Calcite was called Saffron[1] and could find queries in Java-like expressions (similar to LINQ). “Only … from JDBC” means as opposed to queries that had been parsed out of Java code. Julian [1] http://saffron.sourceforge.net/overview.html <http://saffron.sourceforge.net/overview.html> > On May 18, 2016, at 6:16 AM, Michael Franzkowiak <mich...@contiamo.com> wrote: > > Hi all, > > we have a (very basic) custom query DSL for OLAP type queries and are > investigating whether we can replace and improve on our current execution > engine using calcite. > > We believe using the RelBuilder would be a much nicer way to go from our > custom query format to actual DB queries (while offering many potential > benefits - planning process etc. - in the future). > > That said, we’ve run into a small issue: the “scan” method only accepts a > String as a table identifier, meaning that we can’t specify a table of a sub > schema (“db1”.”my_table”). Since RelOptSchema.getTableForMember accepts a > list of Strings for this case we’re wondering whether > > a) there is a reason for only accepting a String (there is a comment in > RelOptSchema.getTableForMember stating that “names.length is only greater > than 1 for queries originating from JDBC”) > > b) scan could be overloaded to accept a List of Strings as well (in which > case we’re happy to make that change) > > Cheers, > Michael
