Comment fonctionnent les transactions de base de données dans Django ?

Question

Accepted Answer

Une **transaction de base de données** regroupe plusieurs opérations afin qu'elles **réussissent toutes ou échouent toutes ensemble** (atomicité) — évitant les mises à jour partielles et incohérentes. Django fournit `transaction.atomic` pour envelopper les opérations dans une transaction, garantissant l'intégrité des données pour les opérations multi-étapes.

## The problem transactions solve

```python
# ❌ WITHOUT a transaction — partial failure leaves inconsistent data
def transfer_money(from_account, to_account, amount):
    from_account.balance -= amount
    from_account.save()                  # ✓ succeeds
    # ...if the server crashes HERE, money vanished from one account...
    to_account.balance += amount
    to_account.save()                    # ✗ never runs → money LOST!
```

Sans transaction, si la deuxième opération échoue, la première a déjà été validée — laissant la base de données dans un état cassé et incohérent (argent débité mais non crédité).

## transaction.atomic — tout ou rien

```python
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)
```

```python
# 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
```

À l'intérieur de `atomic()`, si une opération lève une exception, Django **revient en arrière** sur chaque modification du bloc — de sorte que la base de données ne soit jamais laissée à mi-chemin. En cas de succès, toutes les modifications sont validées ensemble.

## Nested atomic blocks (savepoints)

```python
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
```

Les blocs `atomic` imbriqués utilisent des savepoints — le bloc interne peut revenir en arrière indépendamment sans avorter la transaction externe entière.

## Important details

```text
✓ 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
```

## Pourquoi c'est important

Les transactions de base de données sont essentielles pour **l'intégrité des données** chaque fois qu'une opération implique plusieurs modifications connexes de la base de données qui doivent réussir ou échouer comme une unité — et la compréhension de `transaction.atomic` est une connaissance importante pour construire des applications correctes et fiables.

Le problème fondamental que les transactions résolvent est **l'échec partiel** : sans atomicité, si une opération multi-étapes échoue à mi-chemin (un crash, une exception, une violation de contrainte), la base de données est laissée dans un état incohérent — l'exemple classique du virement bancaire (débité d'un compte mais non crédité à un autre) illustre comment cela corrompt les données et peut avoir des conséquences graves. `transaction.atomic` fournit la garantie que les opérations sont **tout ou rien** (en revenant en arrière sur le bloc entier en cas d'échec), ce qui est nécessaire pour toute opération couvrant plusieurs écritures — créer une commande avec ses lignes, transférer des fonds, mettre à jour des enregistrements connexes — pour maintenir une base de données cohérente.

Comprendre comment utiliser les blocs atomic (comme gestionnaire de contexte ou décorateur), les transactions imbriquées avec savepoints, et les détails importants — capturer les exceptions *en dehors* du bloc, utiliser **`select_for_update()`** pour verrouiller les lignes et prévenir les conditions de concurrence dans les mises à jour concurrentes, et maintenir les transactions courtes pour éviter de conserver les verrous — est une connaissance pratique pour construire des applications robustes.

La cohérence des données est une exigence fondamentale des systèmes fiables, et les transactions sont le mécanisme qui la garantit pour les opérations de base de données multi-étapes, ce qui en fait un sujet important qui distingue les développeurs qui écrivent du code correct et préservant l'intégrité de ceux dont les applications peuvent corrompre silencieusement les données en cas d'échec ou d'accès concurrent — une préoccupation fréquemment pertinente dans toute application traitant des modifications de données importantes et connexes.