Part of #519 (Thrift vs SEA metadata parity).
Problem
list_tables returns different values for several columns between protocols:
| Column |
Thrift |
SEA |
count |
TABLE_TYPE |
"TABLE" |
"VIEW" |
50 |
TABLE_TYPE |
"" (empty) |
"TABLE" |
40 |
REMARKS |
"UNKNOWN" |
"" |
56 |
TABLE_NAME |
"test_result_set_types" |
"test_result_set_types_no_interval" |
36 |
TABLE_NAME |
"no_constraints" |
"no-constraints" |
36 |
Expected
Consistent TABLE_TYPE classification, a single REMARKS default, and identical TABLE_NAME values across protocols.
How JDBC does it
MetadataResultSetBuilder:
TABLE_TYPE: when server type is null/empty, defaults to "TABLE" (≈ line 900). Canonical set: TABLE, VIEW, SYSTEM TABLE, METRIC_VIEW.REMARKS: when no comment, defaults to "" (empty string) — not "UNKNOWN", not null (≈ line 277).
So SEA's REMARKS="" matches JDBC; the Thrift path's "UNKNOWN" is the outlier. The TABLE↔VIEW and table-name differences need investigation (may be two genuinely different objects being matched due to the wildcard issue in #519's wildcard sub-issue, or a view-vs-table classification gap).
Suggested fix
In the shared normalization layer (#519): default REMARKS to "", normalize TABLE_TYPE classification, and confirm the same object set is matched so TABLE_NAME aligns.
Evidence
diff-report-20260615-064733Z.json, where = step[0] / rows[*] / {TABLE_TYPE|REMARKS|TABLE_NAME}.
Part of #519 (Thrift vs SEA metadata parity).
Problem
list_tablesreturns different values for several columns between protocols:TABLE_TYPE"TABLE""VIEW"TABLE_TYPE""(empty)"TABLE"REMARKS"UNKNOWN"""TABLE_NAME"test_result_set_types""test_result_set_types_no_interval"TABLE_NAME"no_constraints""no-constraints"Expected
Consistent
TABLE_TYPEclassification, a singleREMARKSdefault, and identicalTABLE_NAMEvalues across protocols.How JDBC does it
MetadataResultSetBuilder:TABLE_TYPE: when server type is null/empty, defaults to"TABLE"(≈ line 900). Canonical set:TABLE,VIEW,SYSTEM TABLE,METRIC_VIEW.REMARKS: when no comment, defaults to""(empty string) — not"UNKNOWN", not null (≈ line 277).So SEA's
REMARKS=""matches JDBC; the Thrift path's"UNKNOWN"is the outlier. TheTABLE↔VIEWand table-name differences need investigation (may be two genuinely different objects being matched due to the wildcard issue in #519's wildcard sub-issue, or a view-vs-table classification gap).Suggested fix
In the shared normalization layer (#519): default
REMARKSto"", normalizeTABLE_TYPEclassification, and confirm the same object set is matched soTABLE_NAMEaligns.Evidence
diff-report-20260615-064733Z.json,where = step[0] / rows[*] / {TABLE_TYPE|REMARKS|TABLE_NAME}.