To není chyba PDO, je to vlastní transakční správě PostgreSQL. Viz:
- Jak mohu říct PostgreSQL, aby nepřerušil celou transakci, když selže jediné omezení?
- Mohu požádat Postgresql, aby ignoroval chyby v rámci transakce
- Vrácení zpět po chybě v transakci
PostgreSQL nevrací transakci zpět, ale nastavuje ji do stavu přerušeného, kdy ji lze pouze vrátit zpět a kde jsou všechny příkazy kromě ROLLBACK nahlásit chybu:
(Překvapuje mě, že jsem na to nenašel odkaz v oficiální dokumentaci; myslím, že budu muset napsat opravu, abych to zlepšil.)
Tak. Když se pokusíte/chytíte a spolknete výjimku v PDO, zachytíte výjimku na straně PHP, ale nezměníte skutečnost, že transakce PostgreSQL je v přerušeném stavu.
Pokud chcete mít možnost spolknout výjimky a pokračovat v používání transakce, musíte vytvořte SAVEPOINT
před každým prohlášením, které by mohlo selhat. Pokud selže, musíte ROLLBACK TO SAVEPOINT ...; . Pokud bude úspěšná, můžete RELEASE SAVEPOINT ...; . To ukládá databázi další režii pro správu transakcí, přidává zpáteční cesty a rychleji vypaluje ID transakcí (což znamená, že PostgreSQL musí dělat více práce na vyčištění pozadí).
Obecně je vhodnější navrhnout SQL tak, aby za normálních okolností neselhal. Můžete například ověřit většinu omezení na straně klienta, přičemž omezení na straně serveru považujete za druhou úroveň jistoty a zároveň zachytíte většinu chyb na straně klienta.
Tam, kde je to nepraktické, zajistěte, aby vaše aplikace byla tolerantní vůči chybám, aby mohla opakovat neúspěšnou transakci. Někdy je to každopádně nutné – například obecně nemůžete použít body uložení k zotavení z přerušení transakce uváznutí nebo selhání serializace. Může být také užitečné udržovat transakce náchylné k selhání co nejkratší, dělat jen minimum požadované práce, takže máte méně věcí, které musíte sledovat a opakovat.
Takže:Kde je to možné, místo spolknutí výjimky spusťte kód databáze náchylný k selhání ve smyčce opakování. Ujistěte se, že váš kód uchovává záznam informací, které potřebuje k opakování celé transakce v případě chyby, nikoli pouze nejnovější výpis.
Pamatujte, jakékoli transakce může selhat:DBA může restartovat databázi, aby aplikoval opravu, systému může dojít paměť RAM kvůli nekontrolované úloze cron atd. Aplikace odolné proti selhání jsou tedy každopádně dobrým návrhem.
Podpory pro vás alespoň používání výjimek PDO a zpracování výjimek – už jste daleko před většinou vývojářů.