Fascinating. I didn't entertain the idea of putting the context in the transaction, for exactly the reason that Chetan cited. But it does seem like a good answer. (And yes, the transactions are short. Long-running transactions are an anti-pattern in their own right.)
Many thanks for the input! Steve On Tuesday, February 7, 2017 at 10:37:02 AM UTC-8, Dave Cheney wrote: > > 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.
