gistfile1.rb

# Conditional decrement.
#
# Decrement the value of a key only if the current value is greater than
# a specified value.

require 'rubygems'
require 'redis'

r = Redis.new
cond_decr = <<LUA
    local value = tonumber(redis('get',KEYS[1]))
    if value == nil then return {err="Value at key is not integer"} end
    if value > tonumber(ARGV[1])
    then
        value = value - 1
        redis('set',KEYS[1],value)
    end
    return value
LUA

r.set(:x,4)
5.times {
    puts(r.eval(cond_decr,1,:x,0))
}

No problem! :-) It is really cool that you were able to bind Lua to Redis so quickly!

First, thanks for implementing this. It is going to be awesome.

Anyway...something more along the lines of this would be more idiomatic Lua code.

local value = tonumber(redis('get', KEYS[1]))
assert(value, "value at key is not an integer")
if value > tonumber(ARGV[1]) then
    value = value - 1
    redis('set', KEYS[1], value)
end
return value

The Redis/Lua semantics are mostly the same as your code. However, using ("err", "error message") and {err = "error message"} is not very idomatic, and has the potential for confusion. Usually, errors are represented in two ways. For programming errors - i.e. ones that result from incorrectly using a function, such as passing the wrong number or wrong types of arguments - an actual error is raised. For "environmental" errors like malformed input or nonexistent files, the function returns (nil, "error message"). The benefit of that format is that you can use assert(somecall()), and if nil (or false) was returned, it will raise an error for you.

If a Redis command returns an error to Lua, it would be best to return the error as (nil, "error message"). If Lua wants to return an error to the user, the obvious choice would be to raise an actual error and use lua_pcall to catch it on the C side.

Still, this is definitely a good start. I look forward to seeing what happens in the future. And if you run into any problems, your friendly neighborhood lua-l would be happy to help.

Right, I missed that.
Error handling with assert()/error() would be better here, since return nil, "string" is better to be reserved for returning multiple redis values (there is a NIL value in Redis afair).

Any reason why I shouldn't eval a library of functions like https://gist.github.com/951084 and use function calls instead of pass a block of code with every eval? Is the lua context likely to be flushed in some future revision?

BTW global by default will be a pain unless you use local.

@agladysh: I thought that Redis multi-bulk replies were handled by a table. The way I thought the mapping would happen is:

• Integer replies translate to number.
• Bulk replies translate to string.
• Status replies translate to...maybe also string? That may get confusing, but on the other hand you rarely have commands that can return bulks or strings.
• Multi-bulk replies translate to table.
• Nil multi-bulk replies translate to nil.
• Error replies either return (nil, "error") or raise a Lua error. This one may take some experimenting to figure out which works better.

@shirro: The Lua state would probably not be flushed, but it is possible that more advanced sandboxing techniques would prevent that from working. If you wanted to do something like that, you could use string.dump to dump the function to bytecode, store it in a key, and then EVAL something like local f = loadstring(redis.get("myscript.lua")); f()

Hey, thanks for the suggestions. @leafstorm: the translation happens exactly as you described it but for errors.
My point for using {err = ...} is that I want all the errors be single return values for a matter of unification, since in lua you can do something like:

return redis("get",...)

And everything happens in the real command is returned by Redis, BUT for status code reply, for which I should probably use {ok=...}.
Similarly you should be able to call a Redis command without even caring about what he returned, save the reply into a var, and return it later as the user directly called Redis:

reply = redis(".....");
... do more stuff ....
return reply

I think this is much more important compared to Lua idiomatic error handling since what hides inside the above concept is that Redis errors are a data type and not a condition.

Btw nothing is written in the stone as this is an "idea evaluation" branch and we can change everything in the future.

Why don't you declare global functions "set" and "get" instead of putting everything in a "redis" function? It would improve error message consistency: you wouldn't have to create a special error message to tell the user the command is unknown, he would get an "attempt to call nil" kind of error.

@antirez: Yeah, but:

1. That means that errors don't evaluate to false in an if statement.
2. It's very unlike normal Lua behavior, which would probably confuse people who already know Lua.

I still think that representing Redis errors with Lua errors would be the best solution. 90% of the time, errors in Redis represent exceptional conditions like improperly calling a command, which is exactly what Lua errors are used for. If there was a time where not directly erroring to the user was important, you could local ok, result = pcall(redis, "get", somekey). ok would contain true or false depending on whether it worked or not, and result would contain either the result of the operation or the error message.

The {ok = "OK"} is a pretty good idea though.

@doub: Because then he would have to define a C-level function for every single Redis command, not to mention polluting the global namespace to heck.

@leafstorm: If you have a single function, you have to do the dispatch inside the called C function anyway. If there are that many commands to bind, use a code generator. And to avoid polluting global namespace you can put it in a (preloaded) module.

@doub People could do something like https://gist.github.com/952677 if they need it. It might be better to leave such things to third party lua libs and keep the redis code simple.