Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

LargeBinary binds or raises depending on whether the value happens to be valid UTF-8

クローズ
#80 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

@dwaddle がすでに取り組んでいます。

2026年10月17日 から。

  • #82 @dwaddle による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
database

調査の方向性

まず、方言のパラメーターまたはリテラルのレンダリングのエントリーポイントと、既存の LargeBinary の処理を見つけます。無効な UTF-8 の例を再現してから、bytes に対して提案されている hex/unhex 表現を実装します。UTF-8 の妥当性に依存せず、b'\x00\xff' を含むバイナリ値を同一の内容で挿入し、ラウンドトリップできれば完了です。

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

説明

Versions

  • databend-sqlalchemy 0.5.5
  • databend-driver 0.34.2
  • SQLAlchemy 2.0.51
  • Python 3.12.9, macOS
  • Server: datafuselabs/databend:v1.2.925-patch-4 in Docker

What happens

The dialect renders parameters into the statement text, so a bytes value gets decoded as UTF-8 on the way in. Whether a LargeBinary insert works therefore depends on the value, not the type. One value at a time, everything else held constant:

value valid UTF-8 result
b'\x00\x01' yes binds, round-trips identically
b'abc' yes binds, round-trips identically
b'\xc3\xa9' yes binds, round-trips identically
b'\x00\xff' no 'utf-8' codec can't decode byte 0xff in position 1
b'\xff' no same
b'\x80' no same

The database is not the problem. A BINARY column given unhex('00ff') reads back as b'\x00\xff' without complaint.

Why this one bothered me

Valid UTF-8 isn't a property binary data has. So the column works right up until the day the bytes have a high one in them — and a test suite with ASCII-ish fixtures will never see it. That's worse than a flat refusal, because a refusal gets found on day one. I ended up declaring LargeBinary unstorable on this dialect rather than let it fail per value, which loses a column type the database supports perfectly well.

Suggested fix

Hex-encode bytes parameters and emit unhex('…') — the server already accepts that, as above.

Some background, in case it's useful: databendlabs/bendsql#583 asked for real parameter binding in the driver, and interpolating into statement text is what makes bytes unrepresentable here. For what it's worth, trino-python-client gets this wrong from the identical cause — its literal formatter calls .encode() on the value, which is what you'd do to a str. Interpolating parameters into SQL seems to be what gets bytes wrong, whoever does it.

主要言語
Python
スター
15
フォーク
5
平均マージ
1日 15時間
マージ済み PR(30日)
1

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

databendlabs/databend-sqlalchemy のほかの issue

databendlabs/databend-sqlalchemy の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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