Transactions in context values in Golang, is it OK? r/golang

Welcome to the inaugural video about r/golang! Here, I discuss exciting, challenging, relevant, or anything interesting on that subreddit by providing a deep-dive discussion.

This video covers a post that asks:

"Is it an anti-pattern to pass the sql transaction as ctx values through the lifecycle of the request? I am trying to implement a transaction that uses different repositories."

The blunt answer is "Yes", it is an anti-pattern but that does not solve the hypothetical problem, what is, if any, an idiomatic way to reuse repositories and still use transactions?

In this video I cover a way to enable reusability to support repositories with transactions.

== Relevant links

== All Go/Golang Playlists

== Socials

00:00 - Start
00:14 - Is it an anti pattern in golang to use transactions in context values?
00:35 - Repositories, transactions and context
00:57 - What is the repository pattern? What is context? What are transactions?
02:44 - Demo start (Part 1)
03:04 - Transaction Script using a transaction function
03:23 - User repository implementation
03:40 - Role repository implementation
04:25 - UserRole repository implementation
05:17 - Commands using repositories
07:05 - End of Part 1!
07:44 - Queries pattern to reuse logic executing SQL statements
08:15 - Create UserQueries used by User repository
09:09 - Create RoleQueries used by Role repository
10:59 - Create UserRoleQueries used by UserRole repository
11:19 - Summary of steps needed for reusing repositories with transactions
11:53 - Implement UserCloner type to reuse repositories with transactions
14:18 - Demo of UserCloner with command
15:16 - Conclusion

=== Who am I?

Hello 👋🏼! My name is Mario, and I am a Hands-on Software Architect and Lead Backend Engineer with decades of professional experience building all kinds of software, such as on-premise Automation Systems, Linux Accessibility Desktop Applications, Cloud Governance and Compliance Systems, and Distributed Cloud-based Advertising Systems.

The content I produce includes what I've learned while working for small startups and large companies and the processes I've followed for successfully delivering complex enterprise systems from start to end.

Subscribe if you like Software Development, Software Architecture, and Systems Design and of course, Go!

Keep it up. Don't give up!

#golang #transactions #databases

=== Follow us along on Instagram for our family adventures

=== Our affiliate links below

DISCLAIMER: Some of the links shared in the description are affiliate links. As a member of these affiliate programs, I earn a small commission from your purchases at no additional cost. I appreciate your support! 💖

[ckvzqwd]

Hi sir, can you do a full video on go kratos framework??

[martinnorberg]

This doesn't really solve the original problem. The reason we would put the transaction in the context is to be able to use any number of repository functions in conjuction, and have them be part of the transaction automatically, and this should all be orchestrated OUTSIDE of the db-layer. Not inside. You would typically have a service layer that calls one or more functions from the repository layer, and they would all share the transcation implicitly via the context.

That's the problem with transactions in general when building a typical layered app. They are a DB-layer concern but you want to orchestrate it from the service layer so your DB-layer can be composable.

[OleksandrTolstoi]

But what about database abstraction? What if you want to change your database to another, for example MongoDB - everithing will broken. And also, why you put transactions at the persistance layer, IMHO it wouldn't work for long buissines transactions, and transactions without details of implementation should be yoused in domain layer.