Closed GoogleCodeExporter closed 8 years ago
Yes, that is on my roadmap too. Only problem is getting a version that supports
it! I'll take a look at the version you cite...
Original comment by marc.gravell
on 27 Dec 2011 at 11:53
I have asked our sysadmin to verify our version... He suggested to use version
2.2.111, that is what we use in production.. (it's in the 2.2. scripting branch)
https://github.com/antirez/redis/tree/2.2-scripting
Original comment by mark.v...@gmail.com
on 27 Dec 2011 at 1:30
I have made first implementation... It's very rough code, however as a general
concept - it works.. At the end I have added a few test cases.
https://gist.github.com/1524339
Original comment by mark.v...@gmail.com
on 27 Dec 2011 at 4:57
Thanks hugely - sounds promising. Just to set expectation: I'm taking things
leisurely between Xmas and new-year, but will review this (and try sorting out
2.2 on my VM) in the new year.
Original comment by marc.gravell
on 27 Dec 2011 at 5:01
I have added some additional commands, that we needed, but are only supported
in Redis Unstable (they will be fully supported in Redis 2.6)
https://gist.github.com/1836949 is our public draft of following supported
commands:
http://redis.io/commands/eval
Task<string> EvalScriptLoad(int db, bool queueJump, string[] args);
Task<string[]> EvalScriptExists(int db, bool queueJump, params string[] args);
Task<string> EvalScriptFlushAll(int db, bool queueJump);
Task<string> EvalScriptKill(int db, bool queueJump);
//we also added a command that we were missing when debugging (it helps, when
you can put your own string to see in redis monitor screen)
Task<string> ServerEcho( bool queueJump, params string[] args);
Original comment by mark.v...@gmail.com
on 15 Feb 2012 at 4:16
Awesome! I'll try to yank "unstable" to see how it works.
Original comment by marc.gravell
on 15 Feb 2012 at 8:28
I have found a problem, that when running Redis Eval commands (see our link to
gist above) our lua scripts can change current database (example in lua script
would be: redis.call('select',2)). The problem is, that Booksleeve client
library doesn't know the current database for this connection after comming
back from Redis lua call. We can't solve this in Redis lua script as lua script
can't read current database to save it to lua variable that would be selected
before end of script.
Since booksleeve keeps internal database number in RedisCommand.cs (int db) I
think it would be useful to have some method, to reset internal Booksleeve db
number.
Booksleeve would in that case add "select " to next redismessage. Something
like RedisCommand.InvalidateDBNumber();
Original comment by mark.v...@gmail.com
on 1 Jun 2012 at 1:29
sure, makes sense. Of course, it could just issue a SELECT expectedNumber
*after* a LUA script - same effect overall, but no need for an "invalidate"
number.
Original comment by marc.gravell
on 1 Jun 2012 at 5:38
a .Scripting node is now available under the connection; the implementation is
a bit more advanced, handling all the caching etc at the server, and supporting
different return shapes (not just string)
Original comment by marc.gravell
on 17 Oct 2012 at 11:57
Original issue reported on code.google.com by
mark.v...@gmail.com
on 27 Dec 2011 at 10:35