[coverage] Conformance findings: METADATA-036,METADATA-037

Bắt đầu với diff của PR về coverage trong tests/ và các test thất bại đã được nêu cho getTableTypes và flag metadata của metric-view. Theo dõi quá trình liệt kê kiểu bảng của driver và các đường dẫn request Thrift OpenSession hoặc SEA CreateSession. Được xem là hoàn tất khi flag được chuyển tiếp khi được bật, được bỏ qua khi chưa được thiết lập, và cả hai trạng thái đều không bao gồm METRIC_VIEW trong phần liệt kê kiểu.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-nodejs. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-nodejs) is fixed, then flips green as a tripwire.

Findings

• METADATA-036 [sea]: SEA (kernel) getTableTypes reports a fourth METRIC_VIEW entry in the table-type enumeration; the reference reports exactly {SYSTEM TABLE, TABLE, VIEW} in every metric-view-metadata state
  • failing test: getTableTypes — enumerates the table-type namespace as a distinct type list (see the coverage PR diff under tests/)
• METADATA-037 [thrift]: enableMetricViewMetadata leaks into the table-type enumeration on Thrift: flag ON changes getTableTypes from {TABLE, VIEW} to {TABLE, VIEW, METRIC_VIEW}, but the enumeration must be invariant under the flag (the OpenSession session-conf forwarding itself is correct)
  • failing test: metric-view metadata flag — forwarded as a session conf, type enumeration unchanged (see the coverage PR diff under tests/)
• METADATA-037 [sea]: SEA's flag-ENABLED table-type enumeration carries METRIC_VIEW, which the reference never reports in any flag state (CreateSession session_confs forwarding and absence-when-unset are both correct)
  • failing test: metric-view metadata flag — forwarded as a session conf, type enumeration unchanged (see the coverage PR diff under tests/)
• METADATA-036: SEA (kernel) getTableTypes reports a fourth METRIC_VIEW entry in the table-type enumeration; the reference driver reports exactly {SYSTEM TABLE, TABLE, VIEW} in every metric-view-metadata state, so a client building an object-type picker from the enumeration is offered a filter value the reference never reports
• METADATA-037: enableMetricViewMetadata leaks into the table-type enumeration: on Thrift, enabling the flag changes getTableTypes from {TABLE, VIEW} to {TABLE, VIEW, METRIC_VIEW}. The conf governs server-side metric-view OBJECT visibility in an ordinary table listing and must not alter the driver's supported-type list, which the reference keeps invariant across flag states (the session-conf forwarding itself is correct on both thrift and sea)

Reproduce & Expected

METADATA-036 — Validates the driver can enumerate the TABLE TYPES the server supports, as a dedicated type LIST — one row per supported table type, carrying only the type name and reporting no catalog / schema / ta…

Reproduce:

• Enumerate the supported table types with NO catalog / schema / table filter.
  ODBC: SQLTables(catalog="", schema="", table="", table_type="%") — the "%" must be
  the WHOLE table_type argument and the three name arguments must be present-but-empty
  (or NULL); a non-empty name argument is an ordinary table listing, not an enumeration.

Expected (per the shared spec):

• The table-type enumeration completes successfully
• At least one table type is reported
• TABLE and VIEW are always reported by Databricks. Subset check only — SYSTEM TABLE is also reported (the system UC catalog) and must not fail the assertion.
• METRIC_VIEW is NOT part of the table-type enumeration. The reference driver reports exactly {SYSTEM TABLE, TABLE, VIEW} here, in every metric-view-metadata state, so a driver carrying METRIC_VIEW in a static type list diverges and would hand a client a filter value the reference never reports (databricks-odbc#205). Metric-view objects remain discoverable via a regular table listing (METADATA-037), so this exclusion costs no discoverability.
• Every row carries a non-null, non-empty type name
• No duplicate type rows (the enumeration is a distinct set, not a per-table scan)
• The rows are type entries, not table rows: no catalog / schema / table name is reported for any row. ODBC (5-column SQLTables layout): TABLE_CAT, TABLE_SCHEM and TABLE_NAME are NULL, and REMARKS is a non-null empty string per the ODBC non-null convention. Drivers whose table-type result is a single TABLE_TYPE column satisfy this structurally.

METADATA-037 — Validates the driver's metric-view-metadata switch does two INDEPENDENT things correctly (databricks-odbc#205): 1.

Reproduce:

• Open a session with the driver's metric-view-metadata switch ENABLED, then run the
  table-type enumeration exactly as METADATA-036 does (no catalog / schema / table
  filter; ODBC: SQLTables(catalog="", schema="", table="", table_type="%")). Observe
  both the session-open request on the wire and the enumeration result.
• Repeat with the switch UNSET (driver default) and confirm the conf is absent from the
  session-open request while the enumeration result is unchanged.

Expected (per the shared spec):

• completes without an exception
• [thrift] OpenSession request configuration[spark.sql.thriftserver.metadata.metricview.enabled] == 'true'
• [thrift] OpenSession request configuration[spark.sql.thriftserver.metadata.metricview.enabled] is absent
• [sea] CreateSession request session_confs[spark.sql.thriftserver.metadata.metricview.enabled] == 'true'
• [sea] CreateSession request session_confs[spark.sql.thriftserver.metadata.metricview.enabled] is absent
• full assertion contract:

result:
- no_exception: true
  description: Enabling the flag breaks neither session open nor the enumeration
- type: result_not_contains
  column: TABLE_TYPE
  excluded_values:
  - METRIC_VIEW
  description: "Flag ENABLED \u2014 the table-type ENUMERATION is unchanged: still\
    \ no METRIC_VIEW. The\nflag governs server-side object visibility in a regular\
    \ listing, never the driver's\nsupported-type list (the independence claim of\
    \ databricks-odbc#205).\n"
- type: result_contains
  column: TABLE_TYPE
  expected_values:
  - TABLE
  - VIEW
  description: "Flag ENABLED \u2014 the enumeration still reports the normal types,\
    \ i.e. the flag neither\nadds nor removes entries. Subset check (SYSTEM TABLE\
    \ also appears).\n"
protocol:
  thrift:
  - request_field:
      method: OpenSession
      path: configuration[spark.sql.thriftserver.metadata.metricview.enabled]
      equals: 'true'
    description: "Flag ENABLED \u2014 the driver forwards the server session conf\
      \ in the OpenSession\n`configuration` map, with the truthy spelling the server\
      \ accepts (\"true\"), not\nthe driver's own raw flag string. This is the assertion\
      \ that goes RED on a\ndriver that accepts the flag and then drops it.\n"
  - request_field:
      method: OpenSession
      path: configuration[spark.sql.thriftserver.metadata.metricview.enabled]
      present: false
    label: flag_unset
    description: "Flag UNSET (default OFF) \u2014 the conf is NOT sent at all, leaving\
      \ the server's own\ndefault in force. Asserting ABSENCE, not `equals: \"false\"\
      `: a redundant \"false\"\nwould override a server default rather than defer\
      \ to it.\n"
  sea:
  - request_field:
      operation: CreateSession
      path: session_confs[spark.sql.thriftserver.metadata.metricview.enabled]
      equals: 'true'
    description: "Flag ENABLED \u2014 the SEA counterpart: the CreateSession request's\
      \ session-conf map\ncarries the key with value \"true\".\n"
  - request_field:
      operation: CreateSession
      path: session_confs[spark.sql.thriftserver.metadata.metricview.enabled]
      present: false
    label: flag_unset
    description: "Flag UNSET (default OFF) \u2014 the conf is absent from CreateSession,\
      \ deferring to\nthe server's own default.\n"

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/212 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-nodejs; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1165