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

UPDATE that matches no rows still commits a new version

Aperta
  • Qualcosa non va?
#9,807 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
53/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
database

Direzione di ricerca

Start in UpdateJob::commit_impl and trace how num_updated_rows and removed, updated, or new fragments determine whether a commit occurs. The issue identifies no_op_update_ignores_explicit_exact_version as an existing test; extend it or add a focused case that checks the returned dataset version when no rows match. Done means the no-op update returns the input dataset without creating a version, while updates that affect rows still commit.

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

Descrizione

Summary

UpdateBuilder::...execute() commits a new dataset version even when the predicate matches no rows. The commit carries an Operation::Update with no removed, updated or new fragments: it changes nothing, but it still takes a manifest CAS, adds a version to the history, and conflicts with (pre-empts) concurrent writers such as compaction.

Why it matters

Conditional ("compare-and-set") UPDATEs are a common pattern for leases and fenced status writes, e.g.

UPDATE t SET owner = 'pod-a', deadline = 1234
WHERE id IN (...) AND (owner IS NULL OR deadline < now)

When several writers race for the same rows, every loser's UPDATE matches 0 rows and still commits a version. In our deployment (lance 12, GCS), a 356-file ingest burst produced 26 such zero-row Update commits on one table, alongside the real ones. Every commit of that burst pre-empted the table's compaction, so compaction never landed until the burst ended (fragments went from 40 to 384).

Reproduction

let before = dataset.manifest.version;
let result = UpdateBuilder::new(dataset.clone())
    .update_where("id < 0")?          // matches nothing
    .set("name", "'bar'")?
    .build()?
    .execute()
    .await?;
assert_eq!(result.rows_updated, 0);
assert_eq!(result.new_dataset.manifest.version, before); // fails: before + 1

The existing test no_op_update_ignores_explicit_exact_version exercises the same path and passes because it never checks the version.

Proposed fix

In UpdateJob::commit_impl, when num_updated_rows == 0 and there are no removed, updated or new fragments, return the input dataset with rows_updated: 0 instead of committing. Nothing is written in that case, so there is nothing to clean up, and a transaction with no affected rows can never conflict, so skipping it cannot change any outcome except the version number.

Still present on main (checked at v14.0.0-beta.6). A patch with a test, against v12.0.0, is at https://github.com/rotty3000/lance/commit/d21067c02 — happy to open a PR against main.

Lingua principale
Rust
Stelle
7.2k
Fork
913
Merge medio
5g 3h
PR unite (30g)
427

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 lance-format/lance

Tutte le issue di lance-format/lance

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.