Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[coverage] Conformance findings: METADATA-005

Abierto
#510 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
api, database

Línea de trabajo

Comienza con las pruebas xfail de METADATA-005 en tests/ de la PR de cobertura #1413 y compara el comportamiento previsto con la PR de referencia #291. Localiza la implementación de SEA getTypeInfo() del controlador de Node.js y la construcción de su resultado de metadatos. La tarea está terminada cuando el resultado orientado a Thrift coincide con la forma especificada de 18 columnas y 20 filas, y las pruebas de conformidad pasan.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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-005 [sea]: SEA getTypeInfo() synthesises a non-canonical type catalogue: COLUMN_SIZE instead of PRECISION, AUTO_UNIQUE_VALUE instead of AUTO_INCREMENT, an extra 19th INTERVAL_PRECISION column, and 23 rows (extra VARCHAR/TIMESTAMP_NTZ/INTERVAL/VARIANT/VARBINARY/NUMERIC, VOID missing) instead of the canonical 18-column / 20-row Thrift TGetTypeInfoResp shape
    • failing test: getTypeInfo — canonical 20-row corpus, order, cell values, NULLABLE=1 / getTypeInfo — canonical 18-column TGetTypeInfoResp layout (PRECISION/AUTO_INCREMENT, no INTERVAL_PRECISION) (see the coverage PR diff under tests/)
  • METADATA-005: SEA getTypeInfo() synthesises a non-canonical type catalogue: emits COLUMN_SIZE instead of PRECISION and AUTO_UNIQUE_VALUE instead of AUTO_INCREMENT, adds a 19th INTERVAL_PRECISION column, and returns 23 rows (extra VARCHAR/TIMESTAMP_NTZ/INTERVAL/VARIANT/VARBINARY/NUMERIC, VOID missing) instead of the canonical 18-column / 20-row Thrift TGetTypeInfoResp shape, so a wrapper switching Thrift→SEA sees its public getTypeInfo() result change

Reproduce & Expected

METADATA-005 — Validates GetTypeInfo returns the canonical Thrift/HiveServer2 getTypeInfo result for the supported Databricks SQL data types: the 18-column schema, the 20-row type corpus, and the per-type cell va…

Reproduce:

  • Call GetTypeInfo via IsMetadataCommand statement (C# only)

Expected (per the shared spec):

  • GetTypeInfo completes successfully
  • Result contains type information
  • C# Thrift path only
  • Exactly the canonical Thrift/HiveServer2 getTypeInfo column count — not 19. A synthesised result must not add an extra column (the pre-fix kernel carried a 19th INTERVAL_PRECISION column that the Thrift response does not have). Scoped to the Thrift/JDBC-style surface: ODBC SQLGetTypeInfo has its own spec-fixed column set.
  • Column names AND their order match the Thrift getTypeInfo result exactly. The two renames matter for wrappers that read the result positionally or by name: PRECISION (not COLUMN_SIZE) at index 2 and AUTO_INCREMENT (not AUTO_UNIQUE_VALUE) at index 11. Scoped to the Thrift/JDBC-style surface (see SURFACE SCOPE in the description): a driver whose type-info surface is ODBC SQLGetTypeInfo asserts its own canonical column set instead — record that per-driver answer in this entry's status cells.
  • The type catalogue has exactly 20 rows — the Thrift SparkGetTypeInfoUtil.supportedType corpus. Not "at least one type": a synthesised catalogue must neither drop rows nor add types Thrift does not report (the pre-fix kernel listed 24 rows including VARCHAR, TIMESTAMP_NTZ, the two INTERVAL types, VARIANT and VARBINARY, which Thrift does not).
  • The first 17 rows are exactly these type names, in exactly this order — the leading run of the 20-row SparkGetTypeInfoUtil.supportedType corpus. Row ORDER is part of the contract, not just membership: VOID is row 0, and a catalogue that reorders the corpus (or omits VOID) diverges from Thrift even if the same names are present. Only a PREFIX is enumerated because the reference PR diff available when this entry was authored is truncated after CHAR; rows 18–20 are pinned by the row_count: 20 assertion above and should be read off the reference implementation when implementing.
  • Per-type cell values match Thrift. DATA_TYPE codes are java.sql.Types values and must agree with the driver's getColumns type mapping (the historical drift this pins: FLOAT reported as REAL (7), STRING as LONGVARCHAR (-1), BOOLEAN as BIT (-7)). PRECISION is non-null only for the numeric types (and is NULL for STRING/BINARY/CHAR — a synthesised catalogue must not substitute i32::MAX or 255). SEARCHABLE is 3 (typeSearchable) for every type except the complex types ARRAY / MAP / STRUCT, which are 0 (typeNoSearch). CASE_SENSITIVE is true only for STRING.
  • Every row reports NULLABLE = 1 (typeNullable), matching Thrift — not 2 (typeNullableUnknown), which the pre-fix synthesised catalogue used for every row.

Context

Lenguaje dominante
TypeScript
Estrellas
37
Forks
51
Merge medio
10 h 38 min
PR fusionados (30 d)
8

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de databricks/databricks-sql-nodejs

Todos los issues de databricks/databricks-sql-nodejs

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.