Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#80 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@dwaddle ci sta già lavorando.

Dal 17/10/2026.

  • #82 di @dwaddle — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
database

Direzione di ricerca

Inizia individuando il punto di ingresso per la rappresentazione dei parametri o dei literal del dialetto e la gestione esistente di LargeBinary. Riproduci gli esempi di UTF-8 non valido, quindi implementa la rappresentazione hex/unhex suggerita per i bytes. Il lavoro è completato quando i valori binari, incluso b'\x00\xff', vengono inseriti e recuperati identici senza dipendere dalla validità di UTF-8.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
15
Fork
5
Merge medio
1g 15h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di databendlabs/databend-sqlalchemy

Tutte le issue di databendlabs/databend-sqlalchemy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.