6

Est-ce que quelqu'un a de l'expérience à partager en utilisant MySQL savepoints (directement ou via un ORM), surtout dans un service web non-trivial? Où les avez-vous réellement utilisés? Sont-ils assez fiables (en supposant que vous êtes prêt à exécuter une version relativement récente de MySQL) ou trop coûteux ou trop coûteux? Enfin, quelqu'un a-t-il une expérience avec quelque chose comme le cas d'utilisation suivant et avez-vous utilisé des points de sauvegarde pour cela? Supposons que le point principal d'une unité de travail spécifique est d'ajouter une ligne à une table Orders (ou autre chose, ne doit pas nécessairement être liée à une commande, bien sûr) et de mettre à jour une table OrdersAuditInfo, dans la même transaction. Il est essentiel que Orders soit mis à jour si possible, mais la table OrdersAuditInfo n'est pas aussi essentielle (par exemple, il suffit d'enregistrer une erreur dans un fichier, mais continuez avec la transaction globale). À un niveau bas, il pourrait ressembler à ceci (avertissement, pseudo-SQL suit):Utilisations réelles des points de sauvegarde MySQL dans les services Web?

BEGIN; 

INSERT INTO Orders(...) VALUES (...); 
/* Do stuff outside of SQL here; if there are problems, do a 
ROLLBACK and report an error (i.e., Order is invalid in this 
case anyway). */ 

SAVEPOINT InsertAudit; 
INSERT INTO OrdersAudit(...) VALUES(...); 
/* If the INSERT fails, log an error to a log file somewhere and do: */ 
ROLLBACK TO SAVEPOINT InsertAudit; 

/* Always want to commit the INSERT INTO Orders: */ 
COMMIT; 

Mais même ici peut-être il serait mieux (ou au moins plus fréquent) idiome? On pourrait faire l'insertion OrdersAuditInfo dans une transaction complètement différente, mais il serait bon d'avoir la garantie que la table OrdersAuditInfo étaient et non écrit à moins que le COMMIT final ne fonctionne.

Répondre

1

J'ai généralement tendance à éviter les SAVEPOINT, car cela peut rendre le code assez difficile à comprendre et à vérifier.

Dans le cas où vous avez posté, l'emballage dans une seule transaction dépendra de savoir si OrdersAudit enregistrements correspondant exactement à Orders, fait partie de vos règles métier.

EDIT: Il suffit de relire votre question, et vous n'avez pas besoin d'une correspondance garantie entre OrdersAudit et Orders. Donc, je n'utiliserais aucune transaction pour l'insertion des enregistrements OrdersAudit.

+0

La raison pour laquelle je voulais que OrdersAudit fasse partie de la transaction globale était dans le cas où l'insertion dans Orders a échoué au moment de COMMIT pour une raison quelconque. –

Questions connexes