Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

2016. december 11., vasárnap 16:20:51 UTC+1 időpontban Daniel Theophanes a következőt írta: > > I don't think ops in context is how I would clean room design this, but it > is the better of many other options. > > The tx begin is easier, but still difficult when I need to ensure drivers > can

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

I don't think ops in context is how I would clean room design this, but it is the better of many other options. The tx begin is easier, but still difficult when I need to ensure drivers can set custom attributes. The problem with something like you suggested is it deviates too far from the

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

Good question. QueryContext(ctx context.Context, query QueryWithOpts, args ...interface{}) (sql.Rows, error) ? Where type QueryWithOpts struct { fmt.Stringer opts []qryOpt } and func Query(qry string, options ...qryOpt) QueryWithOpts á'lá sql.NamedArg. But this feels just as hacky,

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

How would you put them in query when args are the last ...warm? On Sat, Dec 10, 2016, 22:44 Tamás Gulácsi wrote: > I'd also like to change the API for passing options as Andrè suggested: by > optional funcs. But everywhere - they're not to be in a Context! > > To put them

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

I'd also like to change the API for passing options as Andrè suggested: by optional funcs. But everywhere - they're not to be in a Context! To put them in Context feels a hack. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

Daniel, I agree that multiple queries are commonplace. I was referring to multiple transactions within a single request to be rare, and when it happens you don't necessarily want to share the same (read-only, isolation level) properties. You do have a point that there is a use case for making

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

André, Thanks for the constructive feedback. I agree the signature you propose would be another way to do this. For people who care about these settings, I would expect multiple queries per request is normal and ensuring the props are the same sounds like a benefit, not a detriment. In other

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

Daniel, I would characterize the use case you describe as a very indirect way of setting these options on transactions. That's can be a good thing when contexts are already passed around, and coming up with new ways of passing such options down through a few layers of code is some amount of

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

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,

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

Bump -- Chandra Sekar.S On Wed, Dec 7, 2016 at 10:24 AM, Chandru 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

Re: [go-nuts] Re: Isn't the use of Context in db/sql non-diomatic?

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,