[coverage] Conformance findings: METADATA-005
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
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 undertests/)
- failing test:
- 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.supportedTypecorpus. 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.supportedTypecorpus. 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
- The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-sql-kernel/pull/291 — 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/1413
- Lenguaje dominante
- TypeScript
- Estrellas
- 37
- Forks
- 51
- Merge medio
- 10 h 38 min
- PR fusionados (30 d)
- 8
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de databricks/databricks-sql-nodejs
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
databricks/databricks-sql-nodejs#526 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
databricks/databricks-sql-nodejs#503 ·
Los mantenedores suelen responder en 1 día
-
Docs folder deleted in 1.8.4Abiertoengineer-bot
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
databricks/databricks-sql-nodejs#274 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
databricks/databricks-sql-nodejs#525 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
databricks/databricks-sql-nodejs#524 ·
Los mantenedores suelen responder en 1 día
Todos los issues de databricks/databricks-sql-nodejs
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
AOSSIE-Org/DebateAI#611 ·
Los mantenedores suelen responder en 3 días
-
Upgrade node-libzim to 4.7.0Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
openzim/mwoffliner#2933 ·
Los mantenedores suelen responder en 1 día
-
Use the README category name for website links and submissionsPosiblemente ocupada @dajiaohuang la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
birobirobiro/awesome-shadcn-ui#647 ·
Los mantenedores suelen responder en 2 días
-
Twake Drive picker: closePicker() never destroys the intent (stop() is on the promise returned by start(), not by create())Posiblemente ocupada @chibenwa la tomó hoy. Abiertoclaude
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
linagora/twake-calendar-frontend#1498 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Add: Valea Prahovei TV RO SDAbiertocheck:passed streams:add
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día