


Création d'une exécution de transactions SQL robuste en Go avec un framework générique
Lorsque vous travaillez avec des bases de données SQL dans Go, garantir l'atomicité et gérer les restaurations lors de transactions en plusieurs étapes peut s'avérer difficile. Dans cet article, je vais vous guider dans la création d'un cadre robuste, réutilisable et testable pour exécuter des transactions SQL dans Go, en utilisant des génériques pour plus de flexibilité.
Nous allons créer un utilitaire SqlWriteExec pour exécuter plusieurs opérations de base de données dépendantes au sein d'une transaction. Il prend en charge les opérations sans état et avec état, permettant des flux de travail sophistiqués tels que l'insertion d'entités associées tout en gérant les dépendances de manière transparente.
Pourquoi avons-nous besoin d'un cadre pour les transactions SQL ?
Dans les applications du monde réel, les opérations de base de données sont rarement isolées. Considérez ces scénarios :
Insérer un utilisateur et mettre à jour son inventaire de manière atomique.
Créer une commande et traiter son paiement en garantissant sa cohérence.
Avec plusieurs étapes impliquées, la gestion des restaurations en cas de panne devient cruciale pour garantir l'intégrité des données.
Travailler avec Go dans la gestion Txn.
Si vous écrivez une base de données txn, vous devrez peut-être prendre en compte plusieurs plaques passe-partout avant d'écrire la logique de base. Bien que cette gestion txn soit gérée par Spring Boot en Java et que vous ne vous en souciiez jamais beaucoup lors de l'écriture de code en Java, ce n'est pas le cas en Golang. Un exemple simple est fourni ci-dessous
func basicTxn(db *sql.DB) error { // start a transaction tx, err := db.Begin() if err != nil { return err } defer func() { if r := recover(); r != nil { tx.Rollback() } else if err != nil { tx.Rollback() } else { tx.Commit() } }() // insert data into the orders table _, err = tx.Exec("INSERT INTO orders (id, customer_name, order_date) VALUES (1, 'John Doe', '2022-01-01')") if err != nil { return err } return nil }
Nous ne pouvons pas nous attendre à répéter le code de restauration/commit pour chaque fonction. Nous avons deux options ici : soit créer une classe qui fournira une fonction comme type de retour qui, une fois exécutée dans le defer, validera/annulera txn, soit créera une classe wrapper qui encapsulera toutes les fonctions txn ensemble et s'exécutera en une seule fois.
J'ai opté pour le choix ultérieur et le changement de code est visible ci-dessous.
func TestSqlWriteExec_CreateOrderTxn(t *testing.T) { db := setupDatabase() // create a new SQL Write Executor err := dbutils.NewSqlTxnExec[OrderRequest, OrderProcessingResponse](context.TODO(), db, nil, &OrderRequest{CustomerName: "CustomerA", ProductID: 1, Quantity: 10}). StatefulExec(InsertOrder). StatefulExec(UpdateInventory). StatefulExec(InsertShipment). Commit() // check if the transaction was committed successfully if err != nil { t.Fatal(err) return } verifyTransactionSuccessful(t, db) t.Cleanup( func() { cleanup(db) db.Close() }, ) }
func InsertOrder(ctx context.Context, txn *sql.Tx, order *OrderRequest, orderProcessing *OrderProcessingResponse) error { // Insert Order result, err := txn.Exec("INSERT INTO orders (customer_name, product_id, quantity) VALUES (, , )", order.CustomerName, order.ProductID, order.Quantity) if err != nil { return err } // Get the inserted Order ID orderProcessing.OrderID, err = result.LastInsertId() return err } func UpdateInventory(ctx context.Context, txn *sql.Tx, order *OrderRequest, orderProcessing *OrderProcessingResponse) error { // Update Inventory if it exists and the quantity is greater than the quantity check if it exists result, err := txn.Exec("UPDATE inventory SET product_quantity = product_quantity - WHERE id = AND product_quantity >= ", order.Quantity, order.ProductID) if err != nil { return err } // Get the number of rows affected rowsAffected, err := result.RowsAffected() if rowsAffected == 0 { return errors.New("Insufficient inventory") } return err } func InsertShipment(ctx context.Context, txn *sql.Tx, order *OrderRequest, orderProcessing *OrderProcessingResponse) error { // Insert Shipment result, err := txn.Exec("INSERT INTO shipping_info (customer_name, shipping_address) VALUES (, 'Shipping Address')", order.CustomerName) if err != nil { return err } // Get the inserted Shipping ID orderProcessing.ShippingID, err = result.LastInsertId() return err }
Ce code sera beaucoup plus précis et concis.
Comment la logique de base est mise en œuvre
L'idée est d'isoler le txn dans une seule structure go de telle sorte qu'il puisse accepter plusieurs txns. Par txn, j'entends les fonctions qui feront une action avec le txn que nous avons créé pour la classe.
type TxnFn[T any] func(ctx context.Context, txn *sql.Tx, processingReq *T) error type StatefulTxnFn[T any, R any] func(ctx context.Context, txn *sql.Tx, processingReq *T, processedRes *R) error
Ces deux sont des types de fonctions qui prendront un txn pour traiter quelque chose. Maintenant, dans la couche de données implémentant a, créez une fonction comme celle-ci et transmettez-la à la classe exécuteur qui se charge d'injecter les arguments et d'exécuter la fonction.
// SQL Write Executor is responsible when executing write operations // For dependent writes you may need to add the dependent data to processReq and proceed to the next function call type SqlTxnExec[T any, R any] struct { db *sql.DB txn *sql.Tx txnFns []TxnFn[T] statefulTxnFns []StatefulTxnFn[T, R] processingReq *T processedRes *R ctx context.Context err error }
C'est ici que nous stockons tous les détails du txn_fn et nous aurons la méthode Commit() pour essayer de valider le txn.
func (s *SqlTxnExec[T, R]) Commit() (err error) { defer func() { if p := recover(); p != nil { s.txn.Rollback() panic(p) } else if err != nil { err = errors.Join(err, s.txn.Rollback()) } else { err = errors.Join(err, s.txn.Commit()) } return }() for _, writeFn := range s.txnFns { if err = writeFn(s.ctx, s.txn, s.processingReq); err != nil { return } } for _, statefulWriteFn := range s.statefulTxnFns { if err = statefulWriteFn(s.ctx, s.txn, s.processingReq, s.processedRes); err != nil { return } } return }
Vous pouvez trouver plus d'exemples et de tests dans le dépôt -
https://github.com/mahadev-k/go-utils/tree/main/examples
Bien que nous préférions aujourd'hui les systèmes distribués et les protocoles de consensus, nous utilisons toujours SQL et il existe toujours.
Faites-moi savoir si quelqu'un souhaite contribuer et construire sur cette base !!
Merci d'avoir lu jusqu'ici !!
https://in.linkedin.com/in/mahadev-k-934520223
https://x.com/mahadev_k_
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
Échangez les visages dans n'importe quelle vidéo sans effort grâce à notre outil d'échange de visage AI entièrement gratuit !

Article chaud

Outils chauds

Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Sujets chauds

OpenSSL, en tant que bibliothèque open source largement utilisée dans les communications sécurisées, fournit des algorithmes de chiffrement, des clés et des fonctions de gestion des certificats. Cependant, il existe des vulnérabilités de sécurité connues dans sa version historique, dont certaines sont extrêmement nocives. Cet article se concentrera sur les vulnérabilités et les mesures de réponse communes pour OpenSSL dans Debian Systems. DebianopenSSL CONNUTS Vulnérabilités: OpenSSL a connu plusieurs vulnérabilités graves, telles que: la vulnérabilité des saignements cardiaques (CVE-2014-0160): cette vulnérabilité affecte OpenSSL 1.0.1 à 1.0.1F et 1.0.2 à 1.0.2 Versions bêta. Un attaquant peut utiliser cette vulnérabilité à des informations sensibles en lecture non autorisées sur le serveur, y compris les clés de chiffrement, etc.

Chemin d'apprentissage du backend: le parcours d'exploration du front-end à l'arrière-end en tant que débutant back-end qui se transforme du développement frontal, vous avez déjà la base de Nodejs, ...

La bibliothèque utilisée pour le fonctionnement du numéro de point flottante dans le langage go présente comment s'assurer que la précision est ...

Problème de threading de file d'attente dans Go Crawler Colly explore le problème de l'utilisation de la bibliothèque Crawler Crawler dans le langage Go, les développeurs rencontrent souvent des problèmes avec les threads et les files d'attente de demande. � ...

Dans le cadre du cadre de beegoorm, comment spécifier la base de données associée au modèle? De nombreux projets Beego nécessitent que plusieurs bases de données soient opérées simultanément. Lorsque vous utilisez Beego ...

La différence entre l'impression de chaîne dans le langage go: la différence dans l'effet de l'utilisation de fonctions println et string () est en Go ...

Le problème de l'utilisation de Redessstream pour implémenter les files d'attente de messages dans le langage GO consiste à utiliser le langage GO et redis ...

Que dois-je faire si les étiquettes de structure personnalisées à Goland ne sont pas affichées? Lorsque vous utilisez Goland pour le développement du langage GO, de nombreux développeurs rencontreront des balises de structure personnalisées ...
