Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is this library built around ngx.null instead of Lua's nil? #90

danihodovic opened this issue Jul 8, 2016 · 2 comments


Copy link

danihodovic commented Jul 8, 2016

I've been using the Redis library for the past few months to build an OpenResty application and I've realized that all of the empty responses from the library are wrapped around ngx.null. This make it harder to unit test smaller pieces of code in pure Lua, as standard Lua has no ngx.null value.

It could be mocked when unit testing Lua files, but feels like an ugly workaround. Another issue is that it can't be worked around (by using if not ngx.null) since it's a truthy value which is counter-intuitive.

So why does the lua-resty-redis API return ngx.null instead of using Lua's nil value?

Copy link

agentzh commented Jul 8, 2016

@danihodovic Because of the following reasons:

  1. Lua's nil value in an array-like Lua table can make "holes" in the array, which is troublesome for many things, like with the # operator.
  2. When being returned directly as a single value, we need to distinguish a Lua nil value that indicates a low-level error (like network communication failures or timeout) and a valid redis-land null value.

For unit testing, you can swap your lua or luajit command with the resty command (which is provided by OpenResty under <openresty-prefix>/bin/. See

for the documentation.

Copy link

Thanks, closing 👼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants