sqlite-utils 4.0rc2: tranzakciókezelési hibák javítva Claude Fable segítségével, munkamenet ~149,25 USD-ért

A sqlite-utils 4.0rc2 kiadás elsősorban tranzakciókezelési hibákat javít: több olyan esetet, amikor írások implicit módon maradtak elkötelezetlenül és a kapcsolat bezárásakor visszagördültek. A javítások egy része egy Anthropic Claude Fable nevű kódoló modell segítségével született, majd a változtatásokat GPT-5.5 is átvizsgálta. A munkafolyamat 37 promptot, 34 commitot és összesen +1,321 / -190 sor módosítást jelentett 30 fájlban.

Mi történt és hogyan fedezték fel a hibákat

A szerző korábban már bemutatta a sqlite-utils 4.0rc1-et, és mivel a projekt a SemVer elveit követi, a cél egy olyan 4.0 stabil kiadás elkészítése volt, amely nem tartalmaz kompatibilitást megtörő hibákat. Mivel a szerzőnek csak rövid ideig volt hozzáférése Claude Fable-hez a Max-előfizetés keretében, kipróbálta, hogy a modell segíthet-e a végső hibakeresésben.

Claude Fable egy kezdeti felülvizsgálatot készített, amely több súlyos problémát tárt fel; Fable ötöt jelölt „release blocker”-nek. A legsúlyosabb hibák közé tartozott, hogy a Table.delete_where() metódus nem csomagolt egy saját tranzakciót, így egy DELETE után a kapcsolaton in_transaction=True állapot maradt. Ennek következményeként minden későbbi atomic() hívás a savepoint ágon futott, és soha nem került commitálásra, ami adatok elvesztéséhez vezetett — a szerző bemutatott egy reprodukciós példát, amelyben a törlés és a későbbi beszúrások mind visszagördültek a kapcsolat újranyitásakor.

Munkafolyamat és átdolgozás

A szerző és Fable 37 prompton keresztül dolgozott, 34 commitot készítve, és jelentős kódváltozásokat eszközölve (összesen +1,321 és -190 sor 30 fájlban). A modellezés és javítás során további tervezési finomítások is beépültek. A fejlesztés részben aszinkron módon zajlott: az ügynök néha 10–15 percet töltött egy feladaton, ami alatt a szerző más tevékenységeket végzett, és a mobiljáról promptolta a következő lépést.

A végső ellenőrzést a szerző GitHub PR felületén végezte laptopról, és a dokumentációs változtatások átnézése különösen hasznosnak bizonyult a megértéshez.

A fő változások: tranzakciós modell és API-viselkedés

A 4.0rc2 egyik alapvető változása, hogy minden író művelet — mint insert(), upsert(), update(), delete(), delete_where(), transform(), create_table(), create_index(), enable_fts() és raw db.execute() write utasítások — saját tranzakción belül fut és commitálásra kerül a metódus visszatérése előtt. Ennek következménye, hogy a legtöbb esetben nincs szükség explicit commit() hívásra vagy a DB lezárására a mentéshez.

Két kivételes eset marad, amikor a felhasználónak tudnia kell a tranzakciós viselkedésről:

• Több írási műveletet egyetlen tranzakcióba szeretne csoportosítani: használja a db.atomic() kontextuskezelőt.
• Ha a felhasználó maga kezeli a tranzakciókat db.begin() segítségével: ekkor a könyvtár nem commitál helyette.

A dokumentációban külön megjegyzés szerepel arra vonatkozóan, hogy a Python 3.12+ sqlite3.connect(..., autocommit=True) vagy autocommit=False opciókkal létrehozott kapcsolatok másképp viselkednek, ezért ezek a konfigurációk nem támogatottak — korábban ezek a beállítások a tesztek többségét megbénították, amíg a szerző nem igazította a viselkedést.

GPT-5.5 ellenőrzés és további hibák

A szerző egy másik modellt, GPT-5.5-öt (és Codex Desktopot) is használt a módosítások felülvizsgálatára. Ez további két fontos problémát hozott felszínre:

• db.query() korábban hívta meg self.execute() és csak utána ellenőrizte, hogy a lekérdezés sorokat ad-e vissza; így db.query("update ...") ValueError-t dobhatott, ám a módosítás már commitálva volt — ez meglepő mellékhatásnak számított.
• INSERT ... RETURNING esetén a commit a visszaadott generátor teljes kimerítése után történt, így a db.query("insert ... returning ...") anélkül, hogy iterálnánk rajta, nyitva hagyta a tranzakciót. Ez ellentmondott a dokumentáció és a changelog állításainak.

Claude Fable külön kísérletekkel is megerősítette mindkét problémát, majd a szerző a PR-ben javította ezeket az eseteket, így a db.query() most végrehajtja és commitálja az írási utasításokat a híváskor, és ha egy lekérdezés nem ad sorokat, ValueError-t dob visszagörgetéssel együtt.

Költségbecslés: ~149,25 USD

A szerző ideiglenesen frissített a Claude Max $200/hónap előfizetésre a nagyobb Fable-keret érdekében (korábban $100/hó). Mivel a Fable-hez való hozzáférés július 7-én (a szerző a „July 7th Fablepocalypse”-ként említi) megváltozik, érdekelt volt, mennyibe került volna közvetlenül az API-használat.

Claude képes volt lefuttatni egy AgentsView lekérdezést a munkamenet gyermeksessionjeinek költségbecslésére, és a visszaadott bontás a következő volt:

• Main session (claude-fable-5): $141.02
• API-surface sweep agent (claude-fable-5): $2.40
• Transactions/atomic review agent (claude-fable-5): $2.39
• Post-rc1 commits review agent (claude-fable-5): $1.72
• Migrations review agent (claude-fable-5): $1.40
• Prompt-counting agent (claude-opus-4-8): $0.32
• Összesen: $149.25

A szerző megjegyzi, hogy hosszú távon olcsóbb alacsonyabb besorolású ügynökök használatával dolgozni, de jelen esetben a Max-előfizetés megkönnyítette a feladat elvégzését a rendelkezésre álló időben.

Részletes változások és kompatibilitás

A kiadott rc2 changelog és dokumentáció részletesen felsorolja a változásokat; a fontosabb pontok:

• A db.execute() által végrehajtott write utasítások most automatikusan commitálódnak, kivéve ha már nyitva van egy tranzakció, ilyenkor csatlakoznak hozzá. Ennek hatására azok a kódok, amelyek implicit visszagörgetésre támaszkodtak, most explicit db.begin()-et kell használjanak.
• db.query() most a híváskor hajtja végre a SQL-t; SQL hibák a híváskori ValueError-ral jelennek meg, és INSERT ... RETURNING esetén az eredmény nem marad iterálás nélkül nyitott tranzakcióban.
• A Python API validációs hibái most ValueError-t dobnak AssertionError helyett, mert a korábbi assert használat a -O futtatási mód alatt figyelmen kívül hagyható volt.
• table.upsert() és table.upsert_all() most PrimaryKeyRequired hibát dobnak, ha egy rekord hiányos a primer kulcs tekintetében, ehelyett korábban csendben új sorként kerültek beszúrásra.
• db.enable_wal() és db.disable_wal() most sqlite_utils.db.TransactionError-t dobnak, ha éppen nyitott tranzakció van; korábban a journal mode váltása néma commitot hajtott végre.
• A View osztályon már nincs enable_fts() metódus; full-text search nem támogatott view-okon, és ennek megfelelően AttributeError-t kap a hívó.
• Több kisebb hibajavítás: table.delete_where(), table.optimize(), table.rebuild_fts() immár commitálják a változtatásokat; a drop-table/drop-view parancsok most hibát jeleznek, ha a cél nem a megfelelő típusú objektum; a migrációk tranzakción belül futnak és hibás futás esetén visszagörgethetők; insert({}) most beszúrható DEFAULT VALUES használatával; valamint a migrate parancs több ponton javítva lett.

Új API-k: db.begin(), db.commit() és db.rollback() lehetővé teszik a manuális tranzakciókezelést a db.atomic() mellett.

Következtetés

A 4.0rc2 fontos stabilitási és viselkedésbeli javításokat hoz a tranzakciók kezelésében, és a dokumentációt is tisztázza. A változtatások célja, hogy a felhasználók számára kiszámítható, biztonságos tranzakciós modellt biztosítsanak, megszüntetve a korábbi esetekben előforduló csendes visszagörgetéseket. A hibák felderítése és javítása jó példája volt annak, hogyan használható együtt emberi fejlesztői munka és generatív modellek segítsége egy nyílt forráskódú projekt végső kifényesítésére.

A 4.0rc2 részletes kiadási jegyzéke és a kapcsolódó PR-ek, valamint a Claude Fable és GPT-5.5 munkamenetek átírásai elérhetők a projektben a további ellenőrzéshez.