[coverage] Conformance findings: RESULTFETCH-020

オープン
  • 何か問題がありますか？
#517 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
49/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
database, databases

調査の方向性

Start with the failing TestDuplicateColumnNamesSurviveResultFetch in the coverage PR and trace the SEA/kernel path through kernel.newKernelRows and cdata.ImportCArrowSchema, where duplicate fields trigger the panic. Reproduce with the single-row query, then check row-oriented and Arrow fetches plus multi-chunk and JOIN cases. Done means duplicate column names and both positional values survive every fetch surface without an exception.

索引モデルが issue の本文から書いたものです。

説明

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-go. 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-go) is fixed, then flips green as a tripwire.

Findings

  • RESULTFETCH-020 [sea]: SEA/kernel backend panics with arrow: duplicate field with name "a" (arrow.StructOf via cdata.ImportCArrowSchema in kernel.newKernelRows) for any result with two identically named columns, including a single-row single-chunk SELECT 1 AS a, 2 AS a; the server returns both columns, so the failure is client-side Arrow schema assembly
    • failing test: TestDuplicateColumnNamesSurviveResultFetch (see the coverage PR diff under tests/)
  • RESULTFETCH-020: SEA/kernel backend panics with arrow: duplicate field with name "a" (arrow.StructOf via cdata.ImportCArrowSchema in kernel.newKernelRows) for any result containing two identically named columns, including a single-row single-chunk SELECT 1 AS a, 2 AS a; the server returns both columns correctly, so the failure is client-side Arrow schema assembly

Reproduce & Expected

RESULTFETCH-020 — A query whose result set contains two columns with the SAME name is valid SQL (e.g.

Reproduce:

  • Execute a one-row query with two identically named columns and read the
    result fully, through every fetch surface the driver exposes (row-oriented
    fetch-all / fetch-one, and the native Arrow/columnar accessor if present).
  • Execute a duplicate-named query whose result is large enough to arrive in
    more than one chunk/batch, and read every row. Exercises concatenation of
    multiple equal-schema chunks. Chunk/batch COUNT is server- and driver-
    dependent and is deliberately NOT asserted -- only that all rows and both
    columns survive. ORDER BY id makes the first data row deterministic so the
    two columns can be told apart positionally (0 vs 1000000).
  • Execute a JOIN whose two sides share a column name, so the duplication comes
    from SELECT * rather than from explicit aliasing.

Expected (per the shared spec):

  • completes without an exception
  • result has exactly 1 row(s)
  • result has 2 column(s)
  • col 0 is named a
  • col 1 is named a
  • col 0, row 0 == 1 (type Int32)
  • col 1, row 0 == 2 (type Int32)
  • completes without an exception
  • result has exactly 200000 row(s)
  • result has 2 column(s)
  • col 0 is named a
  • col 1 is named a
  • col 0, row 0 == 0 (type Int64)
  • col 1, row 0 == 1000000 (type Int64)
  • completes without an exception
  • result has exactly 1 row(s)
  • result has 2 column(s)
  • col 0 is named id
  • col 1 is named id
  • col 0, row 0 == 1 (type Int32)
  • col 1, row 0 == 1 (type Int32)

Context

主要言語
Go
スター
53
フォーク
70
平均マージ
2日 12時間
マージ済み PR（30日）
16

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

databricks/databricks-sql-go のほかの issue

databricks/databricks-sql-go の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。