add DoContext and ReceiveContext,use context to control the life

[chenjie199234]

context is mostly used when develop a project

I think the with timeout function can also change to this rule
don't override the readtime

can this be merged and make a new tag?my project need this
by the way,can we fix the tag version number?

[stevenh]

Why not just use pool.GetContext(ctx)?

[chenjie199234]

@stevenh pool.GetContext(ctx) only get a connection.The ctx will not effect the Do function.

pool := &redis.Pool{}
pool.DialCOntext = func(ctx context.Context){
    return redis.DialContext(ctx,"tcp","127.0.0.1:6379"/*here may be some options like DialReadTimeout*/)
}
func BusinessLogic(ctx context.Context) error{
    c,e:=pool.GetContext(ctx)
    //ctx didn't expired now,i can get the connection
    if e!=nil{
        return e
    }
    //.....here did some other logic
    //then the ctx is expired
    //now call the Do function
    c.Do("SET","test","abc")
    //the Do function will success.
    //because the Do function will use the readtimeout which was setted when the connection was created.but it is 0.
}

1.when a connection create,the connection has 2 timeout,readtimeout and writetimeout,they are setted by DialReadTimeout and DialWriteTimeout
2.when a Do was called,the readtimeout will be used if it is not zero.
3.so the context in pool.GetContext(ctx) will only effect the connection create,it will not effect the command exec.

The comment above the GetContext also said this.
If want to control the command's life,redigo support to use the DoWithTimeout function.But I Think DoContext is more useful then DoWithTimeout

[chenjie199234]

@stevenh can this be merged?The opensource's working efficiency is really a nightmare. 0_0!!!

[stevenh]

Few things to address not mentioned in the inline comments:

• How does this deal cancelled context on connections? See Add DoWithCancel #351 for some interesting points, it's not as easy as it first appears.
• Needs tests

[chenjie199234]

@stevenh
Cancel context supported.

[stevenh]

No need to force push as it makes it hard to see the changes I will squash the commits to one on merge anyway.

Here's some more feedback on top of the previous pieces.

[NitroCao]

Any progress on this? It's indeed important :(

[pjebs]

My thoughts

Why are we redefining a brand new context cancelation error type: var ErrContextCanceled = errors.New("redis: context canceled")

Can't we use the one from standard library: https://godoc.org/context#pkg-variables

Lots of people like to check the returned error and compare it to the standard library to distinguish between whether the context was cancelled or whether a deadline exceeded.

2. This PR increases the API surface substantially (and in my opinion excessively).

All that is needed is this added to a v2 Conn interface:

func DoContext(ctx context.Context, commandName string, args ...interface{}) (reply interface{}, err error) {

There should be no need for adding timeout/deadline facilities to make it "appear" more convenient for developers.
Developers can easily do it themselves via the context package.

Alternatively, Conn2 interface can be defined which embeds Conn interface.

[pjebs]

I think maintainer wants to go in this direction: #351

[NitroCao]

Ah, I think I should consider using github.com/go-redis/redis instead :)

[stevenh]

My thoughts

Why are we redefining a brand new context cancelation error type: var ErrContextCanceled = errors.New("redis: context canceled")

Can't we use the one from standard library: https://godoc.org/context#pkg-variables

Lots of people like to check the returned error and compare it to the standard library to distinguish between whether the context was cancelled or whether a deadline exceeded.

Good call, we should definitely do that.

1. This PR increases the API surface substantially (and in my opinion excessively).

All that is needed is this added to a v2 Conn interface:

func DoContext(ctx context.Context, commandName string, args ...interface{}) (reply interface{}, err error) {

There should be no need for adding timeout/deadline facilities to make it "appear" more convenient for developers.
Developers can easily do it themselves via the context package.

Alternatively, Conn2 interface can be defined which embeds Conn interface.

Not sure I follow you there, could you clarify?

[stevenh]

Ah, I think I should consider using github.com/go-redis/redis instead :)

Is there something that is missing that is driving that comment?

[chenjie199234]

@stevenh @NitroCao @pjebs @ash2k
sorry guys,work and life have some change,i will find some time to fix the comments,but it may have some delay

[chenjie199234]

@pjebs @stevenh already changed context error to std lib's error.
test file fixed too

[TheFireMike]

Any updates on this? We would really like to use this library in our Thola project, but Context support is critical for us.

[stevenh]

@TheFireMike this is now merged, sorry I'm not been getting some github emails, so didn't realise this was now complete.

Thanks to everyone for their contributions to this PR.

[KebSeb]

may i ask, why i cant find DoContext in the current realease (v1.8.5)?

[stevenh]

It was merged after v1.8.5.

I've just created v1.8.6

[KebSeb]

this is awesome, thank you very much