[Dolibarr-dev] Intégrtité des transactions da ns Dolibarr

[Eldy]

J'ai modifié partout dans le code les appels de gestion de transactions 
du type

db->query("BEGIN"), db->query("COMMIT") et db->query("ROLLBACK")

par la méthode équivalente d'abstraction de base :

db->begin(),  db->commit() et db->rollback()


La raison est double:
- Puisqu'on utilise une couche d'abstraction pour les accès bases 
(insert, update et delete), autant le faire
pour tout.
- La deuxième est plus vicieuse. Cela permet de gérer des transactions 
dans des methodes unitaires et de pouvoir appeler 2 methodes unitaires, 
chacune protégé par sa transaction dans une meme transaction plus global 
elle meme protégée en transaction sans que le commit de la premier 
emethode unitaire viennent fermer la transaction global.
Je m'explique par un exemple:
Imaginons une classe qui a une methodeA qui fait n inserts (les n 
doivent passer ou aucun, du coup la methodeA est du genre begin; inset n 
fois; commit ou rollback).
Bref, il est possible d'utiliser dans ses pages un appel à la methode A 
avec garantie d'intégrité de ce que fait A
Mais maintenant imaginons que j'ai besoin dans mon code de faire un 
insert puis appel à la methode A puis à nouveau un insert et que j'ai 
besoin d'une garantie d'intégrité sur tout cela.
On aura alors un code de page qui fait:
begin
insert1
appel methodeA (qui fait n inserts au sein de sa propre transaction)
insert2
commit ou rollback

Si on utilise pas la couche d'abstraction, dans la méthode A, comme il y 
a un begin et un commit/rollback, le commit de la méthode A ferme la 
transaction, ce qui valide le insert 1 et les n insert de la méthode A. 
Quoi qu'il arrive après pour le insert2 et qu'on ait commit ou rollback 
en fin de code, c'est en base !. Plus fort, meme si on fait rollback en 
fin, le insert2 sera lui aussi en base car la transaction ayant été 
fermé, il se retrouve hors transaction et mysql effectue donc une 
autocommit pour le insert2. Bref pour l'intégrtité, c'est rapé.
En utilisant le begin et commit/rollback de la couche d'abstraction, 
cela n'arrive pas. Le gestionnaire de base gère les niveaux de transactions:
On peut donc appeler la methode A seule, son contenu sera bien protégé 
par son propre begin et commit/rollback. Mais on peut aussi appeler la 
méthode A au sein d'une transaction plus globale.
La méthode choisi est celle de "compter" le niveau de la transaction 
pour savoir à quel niveau on est et ne pas faire les validations de 
niveau >=2 afin de laisser cela au code qui se trouve au niveau1.
Notons que certains SGBD (Oracle avec certaines options) savent gérer 
les sous-niveaux de transaction naturellement mais ce n'est pas le cas 
de mysql, d'ou l'interet de la couche d'abstraction:
Le codeur n'est pas obliger de faire du code dans lequel il n'y a 
toujours qu'un seul niveau parcequ'il est sous mysql (ce qui 
l'obligerais a allez voir la moindre fonction appellée et ses 
sous-fonctions pour etre sur qu'il n'y a toujours qu'un niveau) mais il 
peut se créer des librairies de fonctions unitaires en transaction tout 
en les utilisant dans des fonctions plus complexes au sein de 
transactions plus globales, sans avoir a toucher ses librairies de 
fonctions unitaires. Si il y a 2, 3, 4 niveaux, peu importe, le niveau 
le plus élevé peut décider du commit ou rollback et cela en tout point 
du code.


--
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
AWStats : http://awstats.sourceforge.net
AWBot : http://awbot.sourceforge.net
CVSChangeLogBuilder : http://cvschangelogb.sourceforge.net