Discussion :

[nadine.mauch]

Bonjour,
Je fais appel à vous car j'ai un problème de compréhension du mécanisme rollback après consultation de nombreux exemples de la doc et du web.
Voici le cas qui m'interesse et donc le contenu de la requête sql que je veux envoyer :
begin isolation level serializable;
insert into table1 ...;
insert into table2 ...;
insert into table3...;
select * from table4 ...;
update (les champs de la table4) ...;
commit;
Je souhaite donc que les opérations du bloc soient réalisée séquentiellement et intégralement. Dans un programme de test en utilisateur isolé, pas de problème.
Si pour prévenir tout problème j'intégre un rollbak comment faut-il procéder
1) oter le commit ; envoyer la requête, tester l'erreur puis envoyer une autre requête avec soit commit soit rollback ?
2) intégrer un savepoint dans le bloc ci-dessus et finir par rollback ? mais quand va-t-il s'executer ? automatiquement tout seul ?
3) un savepoint est-il nécessaire ou l'intruction rollback fait-elle revenir en début de bloc ? où continue le code ? y-a-t-il alors un retry ?
4) s'il n'y a pas de commit, la requête est-elle quand même executée et peut on alors savoir avec pg_last_error s'il y a une erreur et valider la requête avec l'envoi d'un commit ou forcer une restitution de contexte avec l'envoit d'un rollback ?

Note: J'envoie directement mes requêtes sql à postgres à partir de mon code php ; je n'utilise pas d'autre couche logicielle.
Merci

[tse_jc]

Bonjour,

Ce qu'il faut comprendre d'abord c'est ce qu'est une transaction. Je vous invite à consulter les cours de SQLpro sur ce forum sur le sujet ils sont très formateurs.
Ce qu'il faut retenir c'est qu'une transaction sert à exécuter un ensemble de requêtes sur le serveur et amène votre SGBDR à en considérer l'ensemble comme si il n'y en avait qu'une seule.
Un rollback sur une transaction va donc annuler toutes les actions effectuées par votre transaction et ramener votre serveur dans le même état qu'il était avant d'exécuter votre transaction.

A partir de là, tout dépends de votre cahier des charges pour déterminer ce que vous souhaitez faire.
Si votre transaction sert à valider une inscription sur votre site ou votre application par exemple et qu'en cas d'erreur vous souhaitez préserver l'inscription elle-même pour ne pas perdre l'information et éviter de rejouer les logs (wal sur postgres) pour les récupérer et voir où c'est situé le problème dans la transaction, il vous suffit de faire un savepoint juste après cette étape, et en cas d'erreur, faire un rollback to savepoint pour arriver à vos fins.

Dans tous les cas, le commit ne doit pas être enlevé, il vous faut juste intégrer une gestion d'erreur au milieu.

Cordialement,

Jc.