command pipeline with dynamic parameters

[gwelr]

the below code does not work with redis-lua because redis:pipeline() consider the variable "key" and "otherkey" as redis command instead of being part of the command parameter list. Or am I missing something? [quote] local key="foo" local otherkey="bar" val1,val2 = lRedis:pipeline(function() set_cardinality("k:" .. key .. ":list") get("k:" .. otherkey .. ":val") end) lua: test.lua:x: unknown redis command: key [/quote]

[gwelr]

code is: local key="foo" local otherkey="bar" val1,val2 = lRedis:pipeline(function() set_cardinality("k:" .. key .. ":list") get("k:" .. otherkey .. ":val") end) lua: test.lua:x: unknown redis command: key

[nrk]

Are you using the latest version of redis-lua? It's strange because your snippet works for me (well, actually there's another problem I've just noticed but it's unrelated, I'll file a bug myself later).

The local variables key and otherkey should be captured by the closure, can you try with the following snippet and see what happens?

local key = "foo"
local otherkey = "bar"

redis:pipeline(function(g)
    g.print(key)
    g.print(otherkey)
end)

It's a whole different matter if key and otherkey are defined as global variables, this won't work currently in redis-lua:

key = "foo"
otherkey = "bar"

local replies = redis:pipeline(function()
    set_cardinality("k:" .. key .. ":list")
    get("k:" .. otherkey .. ":val")
end)

In this case you should do just like in my first snippet, where the original _G is passed to the closure as an argument:

key="foo"
otherkey="bar"

local replies = redis:pipeline(function(g)
    set_cardinality("k:" .. g.key .. ":list")
    get("k:" .. g.otherkey .. ":val")
end)

Pipeline handling will change for sure in future releases of redis-lua since it's been proved to be error prone in some cases, and this is probably one of them.

[nrk]

I'm going to close this issue in a few days if no further details will be posted in the meanwhile. With the next major release this is getting fixed anyway by using a little different approach for pipelines.

[nrk]

I'm closing this issue since no further details have been provided.