You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was using the pipeline command to do "atomic gets" on a few related items and I found that it was impossible with redis-rb today.
Naive attempt:
@r.set("k1","v1")
@r.set("k2","v2")
@r.pipelined do |pipeline|
v1 = pipeline.get("k1")
v2 = pipeline.get("k2")
end
assert_equal "v1", v1
assert_equal "v2", v2
Running this test fails beacause v1 actually equals nil since the get result hasn't been collected yet.
One way to solve this with minimal work is to return an array with the result of all pipelined operations from the pipelined block. I looked at the code and it turns out this was very easy to implement. All of the results are being collected we just needed to return them at the end of the pipeline block. Now we can write:
v1, v2 = @r.pipelined do |pipeline|
pipeline.get("k1")
pipeline.get("k2")
end
assert_equal "v1", v1
assert_equal "v2", v2
Another way to handle this would be with futures but that would be a bit more magical and would lead people to think they could do things like:
@r.pipelined do |pipeline|
v1_future = pipeline.get("k1")
pipeline.set("k2", v1_future.get)
end
This is not valid since the set command is sent to the server with the parameters already fixed. For now I think returning the values is a neat way to handle the issue. I am sending you a pull request with the change and a test case.
The text was updated successfully, but these errors were encountered:
I was using the pipeline command to do "atomic gets" on a few related items and I found that it was impossible with redis-rb today.
Naive attempt:
@r.set("k1","v1")
@r.set("k2","v2")
@r.pipelined do |pipeline|
v1 = pipeline.get("k1")
v2 = pipeline.get("k2")
end
assert_equal "v1", v1
assert_equal "v2", v2
Running this test fails beacause v1 actually equals nil since the get result hasn't been collected yet.
One way to solve this with minimal work is to return an array with the result of all pipelined operations from the pipelined block. I looked at the code and it turns out this was very easy to implement. All of the results are being collected we just needed to return them at the end of the pipeline block. Now we can write:
Another way to handle this would be with futures but that would be a bit more magical and would lead people to think they could do things like:
This is not valid since the set command is sent to the server with the parameters already fixed. For now I think returning the values is a neat way to handle the issue. I am sending you a pull request with the change and a test case.
The text was updated successfully, but these errors were encountered: