4 ms·

the lua api of redis seems a bit un-lua like, redis.exists('key') would be better also, returning a boolean for exists instead of a number, but it's such a sma

the lua api of redis seems a bit un-lua like, redis.exists('key') would be better also, returning a boolean for exists instead of a number, but it's such a small nit-pick that it hardly wants mention the possibilities this brings is quite huge tho, so quite excited

simonw 15y ago
I quite like that the Lua API is a single function, because it means it completely forward compatible already - the Lua API won't have to have new methods added to it when Redis gets new commands.
- almost 15y ago
  This seems like a really good reason, especially with Redis's focus on code quality and developer fun. That scripting.c is only 382 lines long is very cool :)
- antirez 15y ago
  Exactly, it also means: scripting engine completely decoupled from all the rest. Also it is much simpler to do things like dynamic execution of commands, redis(my_command,"var")... or alike.
  - sztanpet 15y ago
    But it is just as easy to do that will a full userdata in lua. You just hook up the newindex metamethod. Even more powerfull
- sztanpet 15y ago
  I cannot agree with that, it's just as easy to add new methods as to learn to pass a new string as the first argument. How is it more "forward compatible"?
  - simonw 15y ago
    When Redis adds a new command in the future, the Lua API code will already work with that new command without needing any modifications - hence forward compatible.
    - LeafStorm 15y ago
      You could implement a forward-compatible database function table like this: local function accesscommand (t, key) local f = function (...) return redis(key, ...) end t[key] = f return key end db = setmetatable({}, {__index = accesscommand}) function db.hmset (key, values) local t = {} for key, value in pairs(values) do t[#t + 1] = key t[#t + 1] = value end redis("hmset", unpack(t)) end Any command without a function defined in the table would create a closure on the fly that calls that command like normal. (It also stores the closure in the table to speed up future calls.) Commands that could be implemented more elegantly using Lua semantics (like HMSET) have overrides defined in the db table directly, which prevents the closure-generating function from being called.
antirez 15y ago
I think everything should be observed from the point of view of an API designed to implement Redis commands, it is not a an API to access Redis from Lua in actual Lua programs. So the whole point is to expose Redis in Lua in a way that is the most native related to the internals of Redis, and not the most comfortable/high-level.

simonw 15y ago

I quite like that the Lua API is a single function, because it means it completely forward compatible already - the Lua API won't have to have new methods added to it when Redis gets new commands.

almost 15y ago
This seems like a really good reason, especially with Redis's focus on code quality and developer fun. That scripting.c is only 382 lines long is very cool :)
antirez 15y ago
Exactly, it also means: scripting engine completely decoupled from all the rest. Also it is much simpler to do things like dynamic execution of commands, redis(my_command,"var")... or alike.
- sztanpet 15y ago
  But it is just as easy to do that will a full userdata in lua. You just hook up the newindex metamethod. Even more powerfull
sztanpet 15y ago
I cannot agree with that, it's just as easy to add new methods as to learn to pass a new string as the first argument. How is it more "forward compatible"?
- simonw 15y ago
  When Redis adds a new command in the future, the Lua API code will already work with that new command without needing any modifications - hence forward compatible.
  - LeafStorm 15y ago
    You could implement a forward-compatible database function table like this: local function accesscommand (t, key) local f = function (...) return redis(key, ...) end t[key] = f return key end db = setmetatable({}, {__index = accesscommand}) function db.hmset (key, values) local t = {} for key, value in pairs(values) do t[#t + 1] = key t[#t + 1] = value end redis("hmset", unpack(t)) end Any command without a function defined in the table would create a closure on the fly that calls that command like normal. (It also stores the closure in the table to speed up future calls.) Commands that could be implemented more elegantly using Lua semantics (like HMSET) have overrides defined in the db table directly, which prevents the closure-generating function from being called.

antirez 15y ago

I think everything should be observed from the point of view of an API designed to implement Redis commands, it is not a an API to access Redis from Lua in actual Lua programs. So the whole point is to expose Redis in Lua in a way that is the most native related to the internals of Redis, and not the most comfortable/high-level.