Właściwie tak właśnie jest zagnieżdżone transakcje został zaprojektowany dla. Cytuję z dokumentów Oracle:
Tak więc transakcja podrzędna w zwykłej transakcji zagnieżdżonej nie ma nic do powiedzenia na temat tego, jak on, inne dzieci lub rodzic (większa transakcja ) może zachowywać się inaczej niż zmiana wzajemnych danych lub niepowodzenie w przypadku wyjątku.
Ale możesz mu przyznać (transakcja podrzędna ) bardzo ograniczona szansa na głosowanie nad swoim przeznaczeniem poprzez wykorzystanie sub-transaction funkcja jak podano w rails dokumenty
przekazując requires_new: true
User.transaction do
User.create(username: 'Kotori')
User.transaction(requires_new: true) do
User.create(username: 'Nemu')
raise ActiveRecord::Rollback
end
end
Co, jak mówią doktorzy:tworzy tylko „Kotori”. odkąd potężne dziecko „Nemu” zdecydowało się umrzeć w milczeniu.
Więcej szczegółów na temat Zagnieżdżonych reguł transakcji (dokumentacja Oracle )
Aktualizacja:
Aby lepiej zrozumieć, dlaczego koleje nested transactions działa w ten sposób, musisz dowiedzieć się nieco więcej o tym, jak działają zagnieżdżone transakcje na poziomie bazy danych, cytuję z dokumentacja Rails API
:
Ok, więc dokumentacja opisuje zachowanie nested transaction w dwóch wymienionych przypadkach w następujący sposób:
W przypadku połączenia zagnieżdżonego #transaction zachowa się w następujący sposób:
-
Blok zostanie uruchomiony bez robienia czegokolwiek. Wszystkie instrukcje dotyczące bazy danych, które mają miejsce w bloku, są skutecznie dołączane do już otwartej transakcji w bazie danych.
-
Jeśli jednak ustawiono :requires_new, blok zostanie opakowany w punkt zapisu bazy danych działający jako transakcja podrzędna.
Wyobrażam sobie ostrożnie, tylko wyobraź sobie że:
opcja(1) (bez wymaga_new) jest na wypadek, gdybyś używał DBMS, który w pełni obsługuje nested transactions lub jesteś zadowolony z „fałszywego” zachowania nested_attributes
podczas gdy opcja(2) jest obsługa savepoint obejście, jeśli nie.
