You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
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?
The text was updated successfully, but these errors were encountered:
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.
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
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 nongx.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'snil
value?The text was updated successfully, but these errors were encountered: