sql: switch to autocommit (#81133) #667
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/81133-psycopg-autocommit"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Le gain en perfs sera négligeable, mais au moins on n'aura plus le risque d'un .commit() oublié, et pgbouncer devrait mieux faire son travail...
3aa61a31b9
to52d8590d3a
103795643d
to9643572884
9ff33c766b
tof1ff6a9548
f1ff6a9548
tof81abc4d6d
f81abc4d6d
to66be798871
66be798871
to420b0e428b
420b0e428b
to030dd64fa5
030dd64fa5
to1e56c8879e
1e56c8879e
to3e0f038227
3e0f038227
to23a5be501d
23a5be501d
to3f4136c10c
3f4136c10c
to485138b5c0
876c89c5a9
toaa8323561f
eb8b72fd97
to1872c9b03d
1872c9b03d
to584b988cf9
5637972826
tod853c73071
ab8894a060
to84a01f4ad4
Après beaucoup de bagarre avec psycopg2, j'ai lu son code source et j'ai pu enfin comprendre ce qui ne marchait pas.
Du coup ça devrait passer les tests unitaires maintenant, j'ai introduit un @atomic pour pouvoir automatiser les transactions (et surtout les sous-transactions avec des savepoints)...
WIP: sql: switch to autocommit (#81133)to sql: switch to autocommit (#81133)84a01f4ad4
to1e934b355d
1e934b355d
to707611b6f0
707611b6f0
to92a8c72917
J'aime toujours bien l'idée du atomic. Néanmoins tu as gardé guard_postgres or le fait de passer en autocommit casse complètement sa sémantique, le conn.rollback() en cas d'exception n'aura aucun effet sans
conn.autocommit = False
en entrée du décorateur. L'idéal ce serait de pouvoir faireguard_postgres = atomic
et que tout marche toujours.Il y a aussi la séquence
conn.autocommit = False \ .. \ conn.commit() \ conn.autocommit = True
dans rebuild_security qui je pense pourrait être remplacé par un décorateur@atomic
en gardant leconn.commit()
explicite au milieu (ça casse un peu la pureté de atomic() mais l'idée est la même que le code actuel).92a8c72917
to4f6fc63fb0
4f6fc63fb0
to8c9918af13
Pas super fan puisqu'on se retrouverait dans ce cas à balancer plein de transactions et de savepoints sans vraies raisons. Le seul usage qu'il restait à guard_postgres était un appel à capture_exception. Je l'ai retiré du coup en supposant que c'était pris par ailleurs, si ça ne convient pas on peut revoir différemment (intercepter dans WcsPgConnection par exemple)
Je suis d'accord, l'actuel est malheureux, je compte sur le week-end pour trouver une solution sans le .commit()
a0e22e1ff1
to3eddf5f4e4
J'ai toujours pensé que le guard_postgres était aussi là pour donner un comportement transactionnel à certaines de ces fonctions si ce n'est pas le cas, soit.
@ -97,0 +140,4 @@
last_savepoint = conn._wcs_savepoints.pop()
cursor.execute("RELEASE SAVEPOINT \"%s\";" % last_savepoint)
else:
# rollback transaction, or rollback savepoint (and release the savepoint, it won't be used anymore)
Cette partie n'est pas couverte par les tests, c'est quelque chose qui serait possible ?
Boarf, ça compile, c'est déjà ça non ? :)
Oui bien sûr, je pensais qu'on passait dans le rollback sur certains des tests, mais je pense que c'était une version intermédiaire où j'avais ajouté beaucoup trop d'appels à atomic dans le code.
6e82a22c77
todb0d7c58e2
Voilà, tous les chemins du nouveau code Atomic sont testés, avec validation que ça fasse bien des rollback/commit dans le bon sens.
db0d7c58e2
to05673c7c31
05673c7c31
to92b24a04ac
92b24a04ac
to2f4e86d679
(le build jenkins est actuellement en erreur)
2f4e86d679
to4fb129598f
9c2245ea66
to3129abd862
C'est réparé, et je pense que le code est intégrable dans le projet en l'état.
3129abd862
tocabc133a77