Hi Chandra, In my view using context to store value for these uses (Read-Only and Isolation Level) is somewhat of a gray area. They are not a classical request only scope, like a tracing ID, but they also aren't strictly limited to a single request either. Say you wanted to kick off a request, but ensure you don't modify the database in anyway. you could pass in a context with ReadOnly set and any further request function will follow that directive. Similarly, by allowing you to set the Isolation at a higher level, you can effectively influence the behavior of the queries for any subsequent request action.
Should we do it this way? Maybe, maybe not. I think there are benefits to this approach, and I think they can be considered request scoped, even if in the degenerate case they are set at the query level. However, I think it will be really common to set these when dispatching requests in the router and using them for the subsequent requests. Has /report/ prefix? Set to ReadOnly and Isolation X Has /api/ prefix? Set Isolation to Y At least that is how I would envision using them. I have been known to be wrong before. What do you think? -Daniel On Thursday, December 8, 2016 at 11:27:36 PM UTC-8, Chandra Sekar S wrote: > > Bump > > -- > Chandra Sekar.S > > On Wed, Dec 7, 2016 at 10:24 AM, Chandru <chand...@gmail.com <javascript:> > > wrote: > >> I can understand db/sql using Context for cancellation. It is the >> optional arguments to BeginContext like IsolationLevel and read-only flag, >> which are not request-specific, that seem to contradict context's >> documentation. >> >> -- >> Chandra Sekar.S >> >> On Tue, Dec 6, 2016 at 9:50 PM, <parais...@gmail.com <javascript:>> >> wrote: >> >>> Either the doc should be changed or the std lib should follow the spirit >>> of the doc. But my understanding is that context.Context is not just about >>> HTTP request/response cycle but deals with anything that needs cancellation >>> or a resource clean up signal , some kind of DIY RAII . In any case the >>> documentation should be clarified. >>> >>> Le mardi 6 décembre 2016 16:48:48 UTC+1, Chandra Sekar S a écrit : >>>> >>>> Documentation of the context package says, >>>> >>>> "Use context Values only for request-scoped data that transits >>>> processes and APIs, not for passing optional parameters to functions." >>>> >>>> sql.BeginContext introduced in 1.8, uses Context to receive options >>>> like IsolationLevel and read-only flag. These are neither request-specific >>>> nor cross-cutting. They are options that are typically specific to a type >>>> of operation, but common to all requests. >>>> >>>> Isn't this use in db/sql contradicting the recommendation in context's >>>> doc? >>>> >>>> -- >>>> Chandra Sekar.S >>>> >>> -- >>> 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 golang-nuts...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
