Administrative commands cannot be effectively namespaced - deprecation warning

[djones]

I'm seeing:

Passing 'flushdb' command to redis as is; administrative commands cannot be effectively namespaced and should be called on the redis connection directly; passthrough has been deprecated and will be removed in redis-namespace 2.0

When running:

ratelimit.send(:redis).flushdb

I noticed issues #130 #122 #111 #97 are all related to the same warning. I tried out the suggested work around in #111 but it doesn't work for me.

In my particular case this code runs in our test suite and in this context I'm not concerned if namespacing is effective or not.

Perhaps the warning message could help guide us to a fix?

[djones]

Redis.current.flushdb

has fixed the issue for me. I still wonder though if there's a way we can empower those who see the warning with some details on possible alternatives.

[mjnguyenloyalty]

Redis.current.redis.flushdb is what worked for me. (Redis.current.flushdb didn't)

[mikeheft]

Neither worked for me, but I'm also using gem mock_rails not sure if that is causing a problem.

unless Rails.env.test?
  $REDIS = Redis::Namespace.new('recommendation_api',
                               redis: Redis.new(host: Rails.application.config.redis_host, port: 6379, db: 0))
else
  $REDIS = Redis::Namespace.new('recommendation_api', redis: MockRedis.new)
end

EDIT: $REDIS.redis.flushdb got it to work for me

[gonzoinc]

TBH These depreciation warning should be completely removed. This is nothing more than log spam. Some of us use modules that pull redis-namespace in on build and are now stuck dealing with this log spam with zero possible ways to turn it off (since it pulls in from third party gems). I have hundreds of these depreciation warnings spamming my logs every second which makes it pretty much impossible to use my logs within needing to parse out this spam.

These should be behind a development toggle of some sort so that those running this in production environments can turn this spam off.

[rafaelfranca]

How about fixing the places that are generating those deprecation warnings?

You can also disable them yourself by using the Warning module in Ruby.

[gonzoinc]

@rafaelfranca My code is not using it directly, external modules used are pulling it in elsewhere which I don't have access to. I.E. Not My Code! They are also locked to specific versions and will not be using 2.0 so depreciation warning doesn't apply hence log spam.

Disable warning only applies when your not debugging. I can easily disable it when I'm not working on it, but when debugging is when you have no control over disabling the log spam.

I could just as easily fork this, remove the log spam and pull it from our internal Artifactory repo, but as it seems to be a headache for more than just me maybe it should be removed.

[dtmunir]

Agree with @gonzoinc -- why can't these warnings be behind some development flag? No one is looking for these in production

[rafaelfranca]

You can do that by using the Warning module in Ruby. https://ruby-doc.org/core-2.5.0/Warning.html

Those warnings will be still in the library until the offending code is removed. I recommend you to report to the libraries that are calling those methods so they fix the issue before the behavior is removed.

Thank you for the issue.