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.
