- 17 Nov, 2015 2 commits
- 09 Nov, 2015 1 commit
-
-
antirez authored
Arguments arity and arguments type error of redis.call() were not reported correctly to Lua, so the command acted in this regard like redis.pcall(), but just for two commands. Redis.call() should always raise errors instead.
-
- 05 Nov, 2015 2 commits
- 04 Nov, 2015 1 commit
-
-
Jan-Erik Rediger authored
-
- 30 Oct, 2015 6 commits
-
-
antirez authored
Currently this feature is only accessible via DEBUG for testing, since otherwise depending on the instance configuration a given script works or is broken, which is against the Redis philosophy.
-
antirez authored
-
antirez authored
This commit also inverts two stanzas of the code just becuase they are more logical like that, not because currently it makes any difference.
-
antirez authored
-
antirez authored
-
antirez authored
By calling redis.replicate_commands(), the scripting engine of Redis switches to commands replication instead of replicating whole scripts. This is useful when the script execution is costly but only results in a few writes performed to the dataset. Morover, in this mode, it is possible to call functions with side effects freely, since the script execution does not need to be deterministic: anyway we'll capture the outcome from the point of view of changes to the dataset. In this mode math.random() returns different sequences at every call. If redis.replicate_commnads() is not called before any other write, the command returns false and sticks to whole scripts replication instead.
-
- 01 Oct, 2015 1 commit
-
-
antirez authored
-
- 27 Jul, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 6 commits
- 16 Jul, 2015 1 commit
-
-
Jiahao Huang authored
-
- 14 Jul, 2015 1 commit
-
-
Oran Agra authored
-
- 03 Jun, 2015 1 commit
-
-
Ben Murphy authored
-
- 22 Mar, 2015 1 commit
-
-
antirez authored
-
- 20 Jan, 2015 3 commits
-
-
antirez authored
Rationale is that when re-entering, it is likely due to Lua debugging hooks. Returning an error will be ignored in most cases, going totally unnoticed. With the log at least we leave a trace. Related to issue #2302.
-
antirez authored
Instead of calling redisPanic() to abort the server. Related to issue #2302.
-
antirez authored
Related to issue #2302.
-
- 09 Jan, 2015 1 commit
-
-
antirez authored
Before this commit scripts were able to access / create keys outside the set of hash slots served by the local node.
-
- 09 Oct, 2014 1 commit
-
-
Matt Stancliff authored
A few people have written custom C commands because bit manipulation isn't exposed through Lua. Let's give them Mike Pall's bitop. This adds bitop 1.0.2 (2012-05-08) from http://bitop.luajit.org/ bitop is imported as "bit" into the global namespace. New Lua commands: bit.tobit, bit.tohex, bit.bnot, bit.band, bit.bor, bit.bxor, bit.lshift, bit.rshift, bit.arshift, bit.rol, bit.ror, bit.bswap Verification of working (the asserts would abort on error, so (nil) is correct): 127.0.0.1:6379> eval "assert(bit.tobit(1) == 1); assert(bit.band(1) == 1); assert(bit.bxor(1,2) == 3); assert(bit.bor(1,2,4,8,16,32,64,128) == 255)" 0 (nil) 127.0.0.1:6379> eval 'assert(0x7fffffff == 2147483647, "broken hex literals"); assert(0xffffffff == -1 or 0xffffffff == 2^32-1, "broken hex literals"); assert(tostring(-1) == "-1", "broken tostring()"); assert(tostring(0xffffffff) == "-1" or tostring(0xffffffff) == "4294967295", "broken tostring()")' 0 (nil) Tests also integrated into the scripting tests and can be run with: ./runtest --single unit/scripting Tests are excerpted from `bittest.lua` included in the bitop distribution.
-
- 29 Sep, 2014 1 commit
-
-
Juarez Bochi authored
Closes #1960
-
- 10 Sep, 2014 1 commit
-
-
antirez authored
As discussed in issue #1945.
-
- 01 Sep, 2014 1 commit
-
-
Paddy Byers authored
-
- 13 Aug, 2014 1 commit
-
-
antirez authored
-
- 07 Aug, 2014 1 commit
-
-
Matt Stancliff authored
Negative key count causes segfault in Lua functions. Fixes #1842 Closes #1843
-
- 12 Jun, 2014 1 commit
-
-
antirez authored
Lua scripts are executed in the context of the currently selected database (as selected by the caller of the script). However Lua scripts are also free to use the SELECT command in order to affect other DBs. When SELECT is called frm Lua, the old behavior, before this commit, was to automatically set the Lua caller selected DB to the last DB selected by Lua. See for example the following sequence of commands: SELECT 0 SET x 10 EVAL "redis.call('select','1')" 0 SET x 20 Before this commit after the execution of this sequence of commands, we'll have x=10 in DB 0, and x=20 in DB 1. Because of the problem above, there was a bug affecting replication of Lua scripts, because of the actual implementation of replication. It was possible to fix the implementation of Lua scripts in order to fix the issue, but looking closely, the bug is the consequence of the behavior of Lua ability to set the caller's DB. Under the old semantics, a script selecting a different DB, has no simple ways to restore the state and select back the previously selected DB. Moreover the script auhtor must remember that the restore is needed, otherwise the new commands executed by the caller, will be executed in the context of a different DB. So this commit fixes both the replication issue, and this hard-to-use semantics, by removing the ability of Lua, after the script execution, to force the caller to switch to the DB selected by the Lua script. The new behavior of the previous sequence of commadns is to just set X=20 in DB 0. However Lua scripts are still capable of writing / reading from different DBs if needed. WARNING: This is a semantical change that will break programs that are conceived to select the client selected DB via Lua scripts. This fixes issue #1811.
-
- 11 Jun, 2014 1 commit
-
-
antirez authored
It is more straightforward to just test for a numerical type avoiding Lua's automatic conversion. The code is technically more correct now, however Lua should automatically convert to number only if the original type is a string that "looks like a number", and not from other types, so practically speaking the fix is identical AFAIK.
-
- 10 Jun, 2014 1 commit
-
-
Matt Stancliff authored
The new check-for-number behavior of Lua arguments broke users who use large strings of just integers. The Lua number check would convert the string to a number, but that breaks user data because Lua numbers have limited precision compared to an arbitrarily precise number wrapped in a string. Regression fixed and new test added. Fixes #1118 again.
-
- 04 Jun, 2014 2 commits
-
-
antirez authored
I'm not sure if while the visibility is the inner block, the fact we point to 'dbuf' is a problem or not, probably the stack var isx guaranteed to live until the function returns. However obvious code is better anyway.
-
antirez authored
The lua_to*string() family of functions use a non optimal format specifier when converting integers to strings. This has both the problem of the number being converted in exponential notation, which we don't use as a Redis return value when floating point numbers are involed, and, moreover, there is a loss of precision since the default format specifier is not able to represent numbers that must be represented exactly in the IEEE 754 number mantissa. The new code handles it as a special case using a saner conversion. This fixes issue #1118.
-
- 20 May, 2014 1 commit
-
-
antirez authored
-