Fix our fork of qless for Redis 3.2.x #3
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a fix for our fork of qless that incorporates the changes by @diesse in seomoz/qless-core#64, which are designed to fix qless breaking on Redis 3.2.x. It looks like Redis started converting
nil
in Redis intofalse
in Lua. (The current Redis-Lua conversion system is documented under the EVAL command.)The operative change was to update the Lua scripts. (Most of the changes were automatically-introduced whitespace changes.) However, there is also a qless-core submodule located in lib/qless and I wanted to make that consistent with the Lua script changes, so I forked qless-core, created a branch with the changes, and pointed the submodule to that commit. (The Lua scripts are generated by running
make
in qless-core.)On top of that, our fork had been pointing to a somewhat old commit in qless-core, so the branch I made on our fork actually branches off of that and is 1 commit ahead and many commits behind master. When someone has some time, we should see if we can incorporate all of the latest changes in qless-core that have been made since then, either by merging the branch into our fork or just pointing to their repo again if they get around to merging that PR in.