SAVEPOINT w SQLite: zagnieżdżone transakcje z ROLLBACK TO

Savepoint to nazwana zakładka wewnątrz transakcji

Zwykła transakcja działa na zasadzie "wszystko albo nic": wszystko pomiędzy BEGIN a COMMIT albo trafia do bazy razem, albo razem zostaje wyrzucone. Zwykle właśnie o to chodzi, ale czasem przydaje się większa precyzja: "Spróbuj tej porcji zmian, a jeśli coś pójdzie źle, cofnij tylko ją i zachowaj resztę transakcji".

Tym właśnie jest savepoint. Wstawiasz nazwaną zakładkę, wykonujesz jakąś pracę, a potem albo ją zachowujesz (RELEASE), albo przewijasz do zakładki (ROLLBACK TO).

CREATE TABLE accounts (name TEXT, balance INTEGER);
INSERT INTO accounts VALUES ('Ada', 100), ('Boris', 100);

BEGIN;
  UPDATE accounts SET balance = balance - 30 WHERE name = 'Ada';

  SAVEPOINT risky;
    UPDATE accounts SET balance = balance + 30 WHERE name = 'Nobody';
  ROLLBACK TO risky;

  UPDATE accounts SET balance = balance + 30 WHERE name = 'Boris';
COMMIT;

SELECT * FROM accounts;

Obciążenie Ady i uznanie Borisa zostają. Błędna aktualizacja dla Nobody została wycofana bez utraty reszty transakcji.

Trzy polecenia

Całe API to trzy instrukcje:

• SAVEPOINT name: ustawia zakładkę.
• RELEASE SAVEPOINT name: zachowuje pracę wykonaną od zakładki i usuwa zakładkę.
• ROLLBACK TO SAVEPOINT name: cofa wszystko od zakładki, a zakładka zostaje na miejscu, więc możesz spróbować ponownie.

Słowo SAVEPOINT po RELEASE i ROLLBACK TO jest opcjonalne: działają zarówno RELEASE risky, jak i ROLLBACK TO risky.

CREATE TABLE log (msg TEXT);

BEGIN;
  INSERT INTO log VALUES ('start');

  SAVEPOINT step1;
    INSERT INTO log VALUES ('krok 1 wykonany');
  RELEASE step1;

  SAVEPOINT step2;
    INSERT INTO log VALUES ('próba kroku 2');
  ROLLBACK TO step2;
    INSERT INTO log VALUES ('ponowna próba kroku 2');
  RELEASE step2;
COMMIT;

SELECT * FROM log;

Z punktu widzenia końcowej bazy wiersz próba kroku 2 nigdy nie istniał. Cała reszta zostaje zapisana.

Savepointy bez zewnętrznej transakcji

Mały zwrot akcji: możesz wydać SAVEPOINT bez wcześniejszego BEGIN. SQLite po cichu otwiera za ciebie transakcję, a najbardziej zewnętrzny savepoint pełni rolę samej transakcji. RELEASE na tym savepoincie zatwierdza zmiany, a ROLLBACK TO przewija bez zatwierdzania.

CREATE TABLE notes (text TEXT);

SAVEPOINT outer;
  INSERT INTO notes VALUES ('cześć');
RELEASE outer;

SELECT * FROM notes;

Dlatego savepointy są czasem opisywane jako "nazwane transakcje". Jednak mieszanie obu stylów w prawdziwym kodzie wprowadza zamieszanie, więc wybierz jeden. Większość osób używa jawnego BEGIN ... COMMIT jako zewnętrznej granicy, a savepointów tylko jako wewnętrznych punktów częściowego cofania.

Zagnieżdżanie savepointów

Savepointy układają się w stos. Możesz ustawić jeden wewnątrz drugiego i wycofać wewnętrzny, nie ruszając zewnętrznego:

CREATE TABLE items (name TEXT);

BEGIN;
  INSERT INTO items VALUES ('a');

  SAVEPOINT outer;
    INSERT INTO items VALUES ('b');

    SAVEPOINT inner;
      INSERT INTO items VALUES ('c');
    ROLLBACK TO inner;
    -- 'c' zniknęło; 'a' i 'b' wciąż tu są

    INSERT INTO items VALUES ('d');
  RELEASE outer;
COMMIT;

SELECT * FROM items;

Końcowa zawartość: a, b, d. Wycofanie do inner usunęło c, ale praca wykonana przed inner (wstawienie b) została nietknięta, a transakcja trwała dalej.

Wycofanie do zewnętrznego savepointu odrzuca też wszystko, co zrobiono na wewnętrznych poziomach: cały stos powyżej tej nazwy zwija się naraz:

CREATE TABLE items (name TEXT);

BEGIN;
  SAVEPOINT outer;
    INSERT INTO items VALUES ('b');
    SAVEPOINT inner;
      INSERT INTO items VALUES ('c');
  ROLLBACK TO outer;
COMMIT;

SELECT * FROM items;

Zarówno b, jak i c zniknęły. ROLLBACK TO outer przewija wszystko od momentu ustawienia outer, łącznie z inner i wstawieniem c.

Po co używać savepointów?

Klasyczny przypadek to przetwarzanie porcji danych, w której pojedyncze elementy mogą się nie udać bez odrzucania całej porcji. Opakuj każdy element w savepoint, a jeśli coś się nie uda, wycofaj się do savepointu i idź dalej:

CREATE TABLE imports (id INTEGER PRIMARY KEY, value INTEGER CHECK(value > 0));

BEGIN;
  SAVEPOINT row1;
    INSERT INTO imports(value) VALUES (10);
  RELEASE row1;

  SAVEPOINT row2;
    INSERT INTO imports(value) VALUES (-5);  -- nie przeszłoby CHECK
  ROLLBACK TO row2;

  SAVEPOINT row3;
    INSERT INTO imports(value) VALUES (20);
  RELEASE row3;
COMMIT;

SELECT * FROM imports;

W prawdziwym kodzie aplikacji błędne wstawienie zgłasza błąd, a aplikacja go przechwytuje, wydaje ROLLBACK TO i kontynuuje. Dwa poprawne wiersze trafiają do bazy, a błędny nie psuje całej porcji.

W ten sam sposób ORM i narzędzia do migracji realizują zagnieżdżone transakcje: tak naprawdę nie zagnieżdżają bloków BEGIN (SQLite na to nie pozwala), tylko mapują zagnieżdżone wywołania na savepointy.

Na co uważać

Kilka szczegółów, na których potykają się osoby, które dopiero poznają savepointy:

• COMMIT zawsze zatwierdza całą transakcję. Nie ma znaczenia, ile savepointów jest otwartych: COMMIT (lub jego alias END) zamyka całą zewnętrzną transakcję. Nie traktuj RELEASE jak częściowego zatwierdzenia: nic nie jest trwałe, dopóki otaczająca transakcja nie zostanie zatwierdzona.
• ROLLBACK (bez TO) przerywa wszystko. Kończy transakcję i odrzuca wszystkie otwarte savepointy. Używaj ROLLBACK TO name, gdy chcesz, by transakcja trwała dalej.
• Savepoint pozostaje otwarty, dopóki nie zostanie zwolniony albo wycofany. Zapomniane RELEASE nie powoduje utraty danych, ale zakładka po prostu czeka do końca transakcji.
• Nazwy nie muszą być unikalne. Jeśli ustawisz SAVEPOINT s dwa razy, ROLLBACK TO s znajdzie najnowszy. Przydatne przy rekurencji, mylące, jeśli zdarzy się przypadkiem.

Dalej: widoki

Savepointy dają większą kontrolę nad zapisami. Kolejny krok to kształtowanie tego, jak czytasz: zapisanie zapytania jako nazwanego obiektu wielokrotnego użytku, z którego możesz robić SELECT jak z tabeli. To widok i o nim za chwilę.