Databázová transakce seskupuje více operací tak, aby všechny buď uspěly nebo všechny selhaly dohromady (atomicita) — což brání částečným, nekonzistentním aktualizacím. Django poskytuje transaction.atomic pro zabalení operací do transakce, což zajišťuje integritu dat pro vícekrokové operace.
():
from_account.balance -= amount
from_account.save()
to_account.balance += amount
to_account.save()
Bez transakce, pokud druhá operace selže, první již byla potvrzena — databáze zůstane v rozbitém, nekonzistentním stavu (peníze odeslány, ale nepřijaty).
from django.db import transaction
# as a context manager
def transfer_money(from_account, to_account, amount):
with transaction.atomic(): # everything inside is ONE transaction
from_account.balance -= amount
from_account.save()
to_account.balance += amount
to_account.save()
# if ANY operation raises an exception, the WHOLE block is ROLLED BACK
# → either both saves happen, or neither does (atomicity)
# or as a decorator on a whole function/view
@transaction.atomic
def create_order(request):
order = Order.objects.create(...)
for item in items:
OrderItem.objects.create(order=order, ...)
# all-or-nothing: a failure anywhere rolls back the entire order creation
Vnitř atomic(), pokud jakákoli operace vyvolá výjimku, Django vrátí zpět každou změnu v bloku — databáze tedy nikdy není ponechána napůl aktualizovaná. V případě úspěchu se všechny změny potvrdí dohromady.
with transaction.atomic(): # outer transaction
do_something()
try:
with transaction.atomic(): # inner = a SAVEPOINT
risky_operation()
except Exception:
pass # inner rolls back to the savepoint; outer continues
Vnořené atomic bloky používají savepoints — vnitřní blok se může vrátit zpět nezávisle bez přerušení celé vnější transakce.
✓ Catch exceptions OUTSIDE the atomic block (catching inside can break rollback handling)
✓ select_for_update() locks rows within a transaction (prevent race conditions on updates)
with transaction.atomic():
account = Account.objects.select_for_update().get(pk=id) # row locked until commit
✓ ATOMIC_REQUESTS setting wraps EVERY request in a transaction (per-database)
✓ Keep transactions SHORT — long transactions hold locks, hurting concurrency
Databázové transakce jsou nezbytné pro integritu dat, kdykoli operace zahrnuje více souvisejících změn databáze, které musí uspět nebo selhat jako jednotka — a pochopení transaction.atomic je důležitou znalostí pro vytváření správných a spolehlivých aplikací.
Jádrovým problémem, který transakce řeší, je částečné selhání: bez atomicity, pokud vícekroková operace selže v polovině (pád, výjimka, porušení omezení), databáze zůstane v nekonzistentním stavu — klasický příklad převodu peněz (odeslání z jednoho účtu, ale nepřijetí na druhém) ukazuje, jak to poškozuje data a může mít vážné důsledky. transaction.atomic poskytuje záruku, že operace jsou vše-nebo-nic (vrácení zpět celého bloku při jakémkoli selhání), což je nezbytné pro jakékoli operaci zahrnující více zápisů — vytvoření objednávky s jejími položkami, převod finančních prostředků, aktualizace souvisejících záznamů — pro udržení konzistentní databáze.
Pochopení toho, jak používat atomic bloky (jako context manager nebo dekorátor), vnořené transakce s savepoints a důležité detaily — zachycení výjimek mimo blok, použití select_for_update() k uzamčení řádků a prevenci race conditions v souběžných aktualizacích a udržování transakcí krátkých, aby nedocházelo k držení zámků — je praktickou znalostí pro vytváření robustních aplikací.
Konzistence dat je základní požadavek spolehlivých systémů a transakce jsou mechanismem, který ji zajišťuje pro vícekrokové databázové operace, což je důležité téma, které rozlišuje vývojáře, kteří napsat správný, integritu zachovávající kód od těch, jejichž aplikace mohou tiše poškodit data při selháních nebo souběžném přístupu — což je často relevantní problém v jakékoli aplikaci zpracovávající důležité, související změny dat.