An update on Redis and Lua
antirez.com
An update on Redis and Lua
1–10 of 12 posts
Re: An update on Redis and Lua
#2That's cool, but not nuts about JSON. They should include at least one space-efficient format, like messagepack (which is 100% compatible with JSON after encoding / decoding). Of course, this opens the floodgates...
Also, is zlib available?
Re: An update on Redis and Lua
#3This is an interesting turn for Redis.
In my mind, this is the lightweight, NoSQL analog to stored procedures.
Re: An update on Redis and Lua
#4This is an interesting turn for Redis. In my mind, this is the lightweight, NoSQL analog to stored procedures.
I'm sure you simply meant to make this comparison based on the fact that both implementations execute scripted functions on the data store server. However, I think there is a very important distinction that warrants a clarification: Stored procedures are saved on the server and then referenced by name. Redis scripting requires that the code be transmitted in each request.
Antirez goes over this in his original post, here: http://antirez.com/post/redis-and-scripting.html
Re: An update on Redis and Lua
#5> My solution was to convert null (multi) bulk types into false, and the other way around, false returned from Ruby is turned as a null bulk reply.
should read:
> My solution was to convert null (multi) bulk types into false, and the other way around, false returned from Lua is turned as a null bulk reply.
Re: An update on Redis and Lua
#6That's cool, but not nuts about JSON. They should include at least one space-efficient format, like messagepack (which is 100% compatible with JSON after encoding / decoding). Of course, this opens the floodgates... Also, is zlib available?
Zlib is not shipped with Lua. I am sure more stuff will get added though as time goes on.
Re: An update on Redis and Lua
#7This is an interesting turn for Redis. In my mind, this is the lightweight, NoSQL analog to stored procedures.
I'm sure you simply meant to make this comparison based on the fact that both implementations execute scripted functions on the data store server. However, I think there is a very important distinction that warrants a clarification: Stored procedures are saved on the server and then referenced by name. Redis scripting requires that the code be transmitted in each request. Antirez goes over this in his original post,…
"Redis scripting requires that the code be transmitted in each request."
Only until antirez implements the EVALSHA command.
Re: An update on Redis and Lua
#8This is an interesting turn for Redis. In my mind, this is the lightweight, NoSQL analog to stored procedures.
I'm sure you simply meant to make this comparison based on the fact that both implementations execute scripted functions on the data store server. However, I think there is a very important distinction that warrants a clarification: Stored procedures are saved on the server and then referenced by name. Redis scripting requires that the code be transmitted in each request. Antirez goes over this in his original post,…
Redis scripting requires that the code be transmitted in each request.
For now, yes, but antirez has said that he's considering adding an EVALSHA command or something that will execute an existing script by the hash of the source code.
Re: An update on Redis and Lua
#9Earlier quoted context omitted.
I'm sure you simply meant to make this comparison based on the fact that both implementations execute scripted functions on the data store server. However, I think there is a very important distinction that warrants a clarification: Stored procedures are saved on the server and then referenced by name. Redis scripting requires that the code be transmitted in each request. Antirez goes over this in his original post,…
"Redis scripting requires that the code be transmitted in each request." Only until antirez implements the EVALSHA command.
Implemented ;)
Re: An update on Redis and Lua
#10That's cool, but not nuts about JSON. They should include at least one space-efficient format, like messagepack (which is 100% compatible with JSON after encoding / decoding). Of course, this opens the floodgates... Also, is zlib available?
In recent benchmarks, Node's JSON implementation is almost twice as fast as messagepack. I think I'd rather have the more universally used format anyway.