sqlite-utils 3.39.1 fikser slettinger som kom tilbake

Du kjører delete_where(), ser radene forsvinne fra tabellen og lukker tilkoblingen. Neste gang du åpner databasen er radene der igjen. Det er feilen Simon Willison rettet i sqlite-utils 3.39.1, som kom 26. juli.

Årsaken var at delete_where() etterlot tilkoblingen i en åpen transaksjon. Uten en commit ble slettingen rullet tilbake i det tilkoblingen ble lukket, og ingen feilmelding kom underveis. Biblioteket er et Python-verktøy for å manipulere SQLite-databaser fra kommandolinjen eller fra kode, og har 2135 stjerner på GitHub.

Feilen var allerede rettet i 4.0, som kom 7. juli, men Willison valgte å bakportere den til 3.x-serien.

«Vi fikset dette i 4.0, men det er egentlig en feil i 3.x som jeg mener fortjener en punktutgivelse.» — Simon Willison, i sak 815 på GitHub

Det er en fornuftig prioritering. Fireserien kom med bakoverinkompatible endringer, blant annet at table.extract() oppfører seg annerledes og at foreign_keys returnerer dataklasser, så prosjekter som ikke har rukket den migreringen satt igjen med en stille datafeil.

Konsekvensen er verre enn en vanlig krasj, nettopp fordi ingenting varsler deg. Et opprydningsskript som sletter gamle rader kan ha kjørt tilsynelatende problemfritt i månedsvis uten å ha slettet noe som helst. Står du på 3.x og har automatisering som rydder i en SQLite-base, er radene du tror er borte antakelig fortsatt der.

Hva bør du gjøre?

1. Oppgrader til 3.39.1 hvis du står på 3.x, eller til 4.1.1 hvis du kan ta de bakoverinkompatible endringene.
2. Tell radene i tabellene et slettende skript har rørt, og sammenlign med hva loggene sier skulle vært fjernet.
3. Legg eksplisitt commit eller en konteksthåndterer rundt sletteoperasjoner i egen kode, slik at du ikke er avhengig av at biblioteket lukker transaksjonen for deg.