CodeGym /Cours /SQL SELF /Utilisation de SAVEPOINT pour gérer les rol...

Utilisation de SAVEPOINT pour gérer les rollbacks partiels dans les transactions

SQL SELF
Niveau 39 , Leçon 2
Disponible

Imagine que t'es en train d'écrire un bouquin. Mais voilà, tout ne se passe pas toujours comme prévu. Parfois tu ponds tout un chapitre, mais en le relisant tu piges que le 5ème paragraphe est vraiment nul. Tu fais quoi ? Tu vas pas jeter tout le chapitre à la poubelle, hein ? À la place, tu corriges juste les passages qui posent problème.

C'est à peu près comme ça que SAVEPOINT marche dans PostgreSQL. Ça te permet de :

  1. Créer des points de sauvegarde dans une transaction — comme des marque-pages dans un livre.
  2. Revenir à ces points pour annuler une partie des opérations faites, sans rollback toute la transaction.
  3. Poursuivre le taf avec les données restantes, sans tout recommencer depuis le début.

Syntaxe de base de SAVEPOINT

Les commandes liées à SAVEPOINT sont vraiment simples. Voilà le kit de base :

Créer un point de sauvegarde (SAVEPOINT) :

SAVEPOINT savepoint_name;

C'est comme si tu disais : "On va mémoriser cet endroit, au cas où on doive revenir ici plus tard."

Rollback vers un point de sauvegarde (ROLLBACK TO SAVEPOINT) :
ROLLBACK TO SAVEPOINT savepoint_name;

Si un truc foire, tu reviens au SAVEPOINT indiqué et tu annules toutes les modifs faites depuis sa création.

Supprimer un point de sauvegarde (RELEASE SAVEPOINT) :
RELEASE SAVEPOINT savepoint_name;

Ça libère l'endroit où t'avais mis ton "marque-page". Après ça, tu pourras plus rollback à ce point-là.

Exemple simple : achat dans une boutique en ligne

Imaginons qu'on gère une boutique en ligne. Un client ajoute plusieurs articles dans son panier, et on veut faire une transaction qui inclut la validation de la commande et la mise à jour du stock. Mais si une étape foire, on veut annuler juste une partie de la transaction, pas tout.

BEGIN;

-- Étape 1 : Réserver l'article "Livre SQL"
UPDATE inventory SET stock = stock - 1 WHERE product_id = 101;

-- On crée un point de sauvegarde
SAVEPOINT book_reserved;

-- Étape 2 : Réserver l'article "Mug PostgreSQL"
UPDATE inventory SET stock = stock - 1 WHERE product_id = 102;

-- Oups, y'a plus de mugs en stock !
ROLLBACK TO SAVEPOINT book_reserved;

-- On valide les modifs juste pour le livre
COMMIT;

Qu'est-ce qui se passe dans cet exemple ?

  1. On commence la transaction avec BEGIN.
  2. Après avoir réservé le livre, on crée un point de sauvegarde book_reserved. C'est notre premier "checkpoint".
  3. On tente de réserver le mug, mais y'a une erreur (genre, plus de stock).
  4. On rollback au point book_reserved pour annuler juste les modifs liées au mug.
  5. Enfin, on valide les changements pour le livre avec COMMIT.

Exemple plus costaud : traitement de données en plusieurs étapes

Maintenant, imagine que tu bosses sur un système de gestion de commandes où tu dois mettre à jour plusieurs tables : orders (commandes), inventory (stock) et billing (factures). Si ça plante à une étape, t'as pas envie de perdre ce qui a déjà été fait dans les autres tables. C'est là que SAVEPOINT sauve la mise.

BEGIN;

-- Étape 1 : Créer une nouvelle commande
INSERT INTO orders (order_id, customer_id, status) VALUES (1, 123, 'en attente');
SAVEPOINT after_order_created;

-- Étape 2 : Mettre à jour le stock
UPDATE inventory SET stock = stock - 2 WHERE product_id = 101;
SAVEPOINT after_stock_updated;

-- Étape 3 : Effectuer le paiement
INSERT INTO billing (order_id, amount, status) VALUES (1, 100, 'payé');

-- Oups, erreur : carte bancaire refusée !
ROLLBACK TO SAVEPOINT after_stock_updated;

-- On est revenu juste après la maj du stock, mais la commande reste en "en attente".
UPDATE orders SET status = 'échec' WHERE order_id = 1;

COMMIT;

Regarde comment on a découpé la transaction en étapes logiques avec SAVEPOINT et comment on est revenu au bon endroit, en gardant une partie des changements.

Astuces utiles avec SAVEPOINT

  • Utilise des noms de points de sauvegarde qui ont du sens. Dans les exemples ci-dessus, after_order_created est bien plus parlant que juste step1.
  • Les points de sauvegarde imbriqués marchent nickel : tu peux créer un SAVEPOINT même après un rollback vers un autre point.
  • Pense à libérer les points inutiles avec RELEASE SAVEPOINT. Ça peut booster les perfs, surtout dans les grosses transactions.

Scénarios d'utilisation dans la vraie vie

Traitement d'opérations bancaires : Par exemple, quand tu transfères de la thune entre plusieurs comptes, tu peux rollback à une étape précise si un des virements foire.

Import de données depuis des fichiers : Si tu importes un gros fichier CSV, tu peux checker chaque ligne et rollback juste pour les données qui plantent, en gardant celles qui passent.

Mise à jour massive d'enregistrements : Si t'as un script SQL bien velu qui met à jour des milliers de lignes, SAVEPOINT te permet de revenir à l'étape précédente si ça plante au milieu.

Erreurs courantes et pièges

Parfois, utiliser SAVEPOINT peut donner des résultats chelous si tu piges pas bien comment ça marche. Par exemple :

  • Si t'oublies de rollback ou de supprimer un point de sauvegarde, tu peux te retrouver avec des ressources bloquées jusqu'à la fin de la transaction.
  • SAVEPOINT peut pas annuler ce qui s'est passé avant sa création. Genre, les données validées avec COMMIT, c'est trop tard pour les rollback.

Maintenant tu peux bidouiller tranquille dans tes transactions, en créant des points de sauvegarde là où il faut. On va continuer à s'entraîner sur SQL, alors prépare-toi pour la suite des aventures !

Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION