I guess it depends on how long your transaction lasts for; it doesn't sound like it lives for that long. IMO the advice about storing contexts in other objects is more about "don't put this into a long lived object", like your server's main loop or something.
On Wednesday, 8 February 2017 05:12:57 UTC+11, Chetan Gowda wrote: > > @Dave, isn't storing context in some struct considered anti-pattern? From > the package doc: > " > Programs that use Contexts should follow these rules to keep interfaces > consistent across packages and enable static analysis tools to check > context propagation: > > Do not store Contexts inside a struct type; instead, pass a Context > explicitly to each function that needs it. The Context should be the first > parameter, typically named ctx > " > > In this case, what are the drawbacks of storing transaction in the context? > I wrote some general comments about context.Value here, https://dave.cheney.net/2017/01/26/context-is-for-cancelation, Peter Bourgon has also written about using conext.Value https://peter.bourgon.org/blog/2016/07/11/context.html, as has Jack Lindamood, https://medium.com/@cep21/how-to-correctly-use-context-context-in-go-1-7-8f2c0fafdf39 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
