Feature: ExecBackground()

[VottusCode]

Simple improvement to add an ExecBackground function to reduce the following boilerplate:

var client *PrismaClient

// ...

func Fetch() {
  // Reduce `.Exec(context.Background())` to `.ExecBg()` or `.ExecBackground()`
  client.User.FindUnique(client.User.ID.Equals(auth[1])).Exec(context.Background())
}

[VottusCode]

Or, make the context argument in the .Exec() function optional and by default use context.Background()

[steebchen]

Thanks for the suggestion. We thought about this as well, but we don't want to make the parameter optional because it should be enforced everywhere (or not).

I think .ExecBackground could be a better solution – the question I'd ask you is .ExecBackground() so much better than .Exec(context.Background())? How often do you need a background context compared to not needing it?

[VottusCode]

Thanks for the suggestion. We thought about this as well, but we don't want to make the parameter optional because it should be enforced everywhere (or not).

I think .ExecBackground could be a better solution – the question I'd ask you is .ExecBackground() so much better than .Exec(context.Background())? How often do you need a background context compared to not needing it?

I basically always use the background context, and repeating myself all the time is very annoying. I think there could be .ExecXX for the default contexts, such as Bg, TODO, etc.

[steebchen]

Can I ask what kind of application you are writing or why you don't care about the context?

[VottusCode]

Can I ask what kind of application you are writing or why you don't care about the context?

A simple REST API. I don't think that more than context.Background() is required for my use.

[steebchen]

So you are writing a REST API server, or are you using one with a REST client? In the case of the server, couldn't you use r.Context() as the context where r is *http.Request?

[VottusCode]

Will do. Still, i think my request is still applicable and background context will be used in a lot of microservices (which Go is used with a lot).

[steebchen]

If the microservices have a any kind of API then you would also use the http's requests context. You could do that even in a CLI, where sending a SIGINT could cancel a context which would cancel the db context as well when it hits a timeout.

I of course do agree with you that there are some cases where you need a background context, like in a seed script, or when there is a continuous process going on and probably other use-cases. I just try to point to use the context whenever possible as it's a best practice directly from the Go language.

[VottusCode]

If the microservices have a any kind of API then you would also use the http's requests context. You could do that even in a CLI, where sending a SIGINT could cancel a context which would cancel the db context as well when it hits a timeout.

I of course do agree with you that there are some cases where you need a background context, like in a seed script, or when there is a continuous process going on and probably other use-cases. I just try to point to use the context whenever possible as it's a best practice directly from the Go language.

Yeah, of course. But as you pointed out, the background context is needed in some cases, like seeders or some automated tasks i suppose. Even then, I don't think generating few extra .Exec functions for default Context implementations provided by Go wouldn't cause that much damage, right?