[CALCITE-3449] Sync the table name logic from TableScan into the TableModify

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.21.0
• Fix Version/s: 1.22.0
• Component/s: core
• Labels: pull-request-available
• Assignee: Danny Chen
• Reporter: Zhuang
• Created: 25/Oct/19 13:26
• Updated: 06/Mar/20 04:34
• Resolved: 01/Nov/19 06:18

Description

When sending queries to target databse, sub schemas should be removed from the sql, but not for modify statement(update\delete\insert). For example, 

delete from "sub_schema".target_table where ...

will send following sql to target database

delete from "sub_schema".target_table where ... 

But select quries worked as expect.

select * from "sub_schema".target_table

will be translated into following and send to target databse.

select * from target_table

I've done some inspect, and find that the code are different. In org.apache.calcite.rel.rel2sql.RelToSqlConverter.java, the table names have sub schemas in it.
 

RelToSqlConverter.java

public Result visit(TableModify modify) {
 final Map<String, RelDataType> pairs = ImmutableMap.of();
 final Context context = aliasContext(pairs, false);

// Target Table Name
 final SqlIdentifier sqlTargetTable =
 new SqlIdentifier(modify.getTable().getQualifiedName(), POS);

But in select query , the table name are just table name, without sub schema.

Bar.java

public Result visit(TableScan e) {
    final SqlIdentifier identifier;
    final JdbcTable jdbcTable = e.getTable().unwrap(JdbcTable.class);
    if (jdbcTable != null) {
      // Use the foreign catalog, schema and table names, if they exist,
      // rather than the qualified name of the shadow table in Calcite.
      identifier = jdbcTable.tableName();
    } else {
      final List<String> qualifiedName = e.getTable().getQualifiedName();
      identifier = new SqlIdentifier(qualifiedName, SqlParserPos.ZERO);
    }

I'm really new to Caicite and commit issues, thanks!
 

Issue Links

• is related to: CALCITE-2914 Improve how LatticeSuggester deduces foreign keys
• links to: GitHub Pull Request #1541