Real life example of "Transactions in context values"

[MarioCarrion]

From the comments section on youtube

@martinnorberg7940

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.

@MarioCarrion

I disagree with you, txn orchestration shouldn't be part of the service layer because:

• It leaks db-details into that layer, and
• Makes "service" harder to test because now we have to mock a db and deal with the happy/error paths, which is outside of the goal of this layer.

The goal of this video, and really the blog, is to implement repositories in such a way that could be composable (that's why the use "DBTX").

If you prefer orchestrating db-calls using the service layer, then go for it.

@martinnorberg7940
@MarioCarrion Well if we ignore testing and leaking db details, because that's a separate discussion, how do you create a good composable repository layer if the service layer is not responsible for orchestrating?

Let's say I have simple CRUD methods on the repo, but in the service layer, I have some specific business logi that requires me to fetch, create, delete, fetch again, and then update, all in one transaction, how do you handle that? This is a real world example from my job.

[MarioCarrion]

Let's say I have simple CRUD methods on the repo, but in the service layer, I have some specific business logi that requires me to fetch, create, delete, fetch again, and then update, all in one transaction, how do you handle that? This is a real world example from my job.

It depends, but the foundation would be to do something similar to what UserCloner.Clone does, which is effectively the orchestrator in this case.

[Catgroove]

I'm interested to know more about this "fault" you mentioned, because I've never heard of that before.

That's for another discussion. Apologies for drifting away from the main topic.

If you move a lot of the business logic to the storage layer, you might end up with weird situations as mentioned in this article: https://threedots.tech/post/database-transactions-in-go/.

Your example only works because all of the business logic is storage logic, but what if you need to do two DB operations, then an external API call, and then another DB operation, all in the same transaction. How would you handle that?

[MarioCarrion]

Sorry, but can you list the weird situations?

Your example only works because all of the business logic is storage logic, but what if you need to do two DB operations, then an external API call, and then another DB operation, all in the same transaction. How would you handle that?

Other than calling an external API, the example I shared with you before already does most of what you're asking, if there's a need to add a type to fetch data from a external type, then that becomes a new argument:

// APIFetcher fetches remote values, of course a better name should be used.
type APIFetcher interface {
  GetValues() ([]Value, error)
}

func (u *UserCloner) Clone(ctx context.Context, id uuid.UUID, name string, fetcher APIFetcher) (internal.User, error) {
   // ...
   // fetcher.GetValues() is called here like any other type.
   // ...
}

[Catgroove]

Sorry, but can you list the weird situations?

https://threedots.tech/post/database-transactions-in-go/images/6-tx-in-repository_hu2491433a23c97e14e4debce027c94fe6_163946_1173x1397_resize_q80_h2_lanczos_3.webp basically this, and sort of what I alluded to before, where the storage layer needs to do something non-storage related between storage operations.

But then, if you're going this route, I would not call your layer a pure storage layer, but a hybrid between a service and a storage layer, which is also what I was talking about earlier with:

Now, this might expose a fault of the regular handler-service-storage pattern that I've seen people deviate from lately.

I don't think passing fetcher's and stuff like that to storage functions makes a whole ton of sense IF you have these three layers, but if you only have a handler and then a hybrid of service and storage, then sure. The "fault" in this situation is trying too adhere to the three layers too strictly, which causes this original problem of transactions in the first place. If you had no layers, you would not have this discussion.

[MarioCarrion]

Yes, agree this is not a pure storage layer; we have the same understanding of how repositories should work where they should only deal with data access, but considering the requirements you mentioned I think that's the "best" approach, I'm willing to make that tradeoff.

With that being said, historically when dealing with external data that requires to be saved I either do two things:

1. Request external data before passing those values to the data layer, or
2. Augment records afterwards, meaning "shell records" are created first and then asynchronously augmented with the external data or deleted afterwards.

Those two options perhaps don't work in your case, and they have tradeoffs as well.

Good discussion nevertheless!