redis-store / redis-activesupport Goto Github PK

Redis stores for ActiveSupport

Home Page: http://redis-store.org/redis-activesupport

License: MIT License

Ruby 100.00%

redis-activesupport's Introduction

Redis stores for Ruby frameworks

Redis Store provides a full set of stores (Cache, I18n, Session, HTTP Cache) for modern Ruby frameworks like: Ruby on Rails, Sinatra, Rack, Rack::Cache and I18n. It supports object marshalling, timeouts, single or multiple nodes, and namespaces.

Please check the README file of each gem for usage and installation guidelines.

Redis Installation

Option 1: Homebrew

MacOS X users should use Homebrew to install Redis:

brew install redis

Option 2: From Source

Download and install Redis from the download page and follow the instructions.

Running tests

git clone git://github.com/redis-store/redis-store.git
cd redis-store
bundle install
bundle exec rake

If you are on Snow Leopard you have to run env ARCHFLAGS="-arch x86_64" ruby ci/run.rb

Contributors

https://github.com/redis-store/redis-store/graphs/contributors

Versioning

The redis-store family of gems uses Semantic Versioning, meaning gems depending on redis-store can be reliably inclusive of any version between the current and the next major. We recommend the following dependency in your library's gemspec:

s.add_dependency 'redis-store', '>= 1.4', '< 2'

Status

Copyright

2009 - 2013 Luca Guidi - http://lucaguidi.com, released under the MIT license.

redis-activesupport's People

Contributors

Stargazers

Watchers

Forkers

centronet-marketing cezarsa wpeterson bjones 10io samleb notethan mmolchan-carecloud arion cef drobtravels updater insales traxtechnologies ajkovar lxbrito mjtko robbiegill raldred brigade bukk530 jorgevbo herminiotorres picocandy tobz basecamp eric-guo exoszajzbuk mcfiredrill braintreeps natesalisbury ridecharge claudiofullscreen razum2um claudiob empact chaffeqa tumayun marcroberts wonderweblabs joshvar88 leeacto andruby ignatiusreza openbl rekhasampath jpascal edwardzhou noafroboy edfinity zocoi bobochka jeroenvisser101 gropher amirmingaliev deliveroo mksm venuenext danielcooper dougpetronilio mjc-gh feeligo film42 marclapierre pikachuexe ccutrer crowdflower dinorosic tarzan learnupon angelfan sathia27 caulfield ronaldshopline juliocaminha mauriciomta eitoball jdatti lokanadham100 hsbt afrojun rikanu ojab trevorrjohn troysurrett ecotonata minimsecure skunkworker lomey mgadikota-rpx tldev sunny debian soartec-lab sergiodj jacobmoretti miguelzamora13

redis-activesupport's Issues

the #fetch_multi key?

In the #fetch_multi :
this line, the block's second params is (name, _), which will only use first and drop the rest params.
I see the super code that is different from it.
Can you tell me why? Thanks.

TypeError: can't dup NilClass on v5.0.2+

Command:
bundle exec rake assets:precompile --trace
Error:

** Invoke assets:precompile (first_time)
** Invoke assets:environment (first_time)
** Execute assets:environment
** Invoke environment (first_time)
** Execute environment
rake aborted!
TypeError: can't dup NilClass
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/redis-activesupport-5.0.4/lib/active_support/cache/redis_store.rb:46:in `dup'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/redis-activesupport-5.0.4/lib/active_support/cache/redis_store.rb:46:in `map'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/redis-activesupport-5.0.4/lib/active_support/cache/redis_store.rb:46:in `initialize'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/cache.rb:57:in `new'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/cache.rb:57:in `lookup_store'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/application/bootstrap.rb:65:in `block in <module:Bootstrap>'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/initializable.rb:30:in `instance_exec'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/initializable.rb:30:in `run'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/initializable.rb:59:in `block in run_initializers'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:228:in `block in tsort_each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:431:in `each_strongly_connected_component_from'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:349:in `block in each_strongly_connected_component'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:347:in `each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:347:in `call'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:347:in `each_strongly_connected_component'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:226:in `tsort_each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/tsort.rb:205:in `tsort_each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/initializable.rb:58:in `run_initializers'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/application.rb:353:in `initialize!'
/home/user/app/config/environment.rb:5:in `<top (required)>'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:292:in `require'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:292:in `block in require'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:258:in `load_dependency'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:292:in `require'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/application.rb:329:in `require_environment!'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/railties-5.1.4/lib/rails/application.rb:445:in `block in run_tasks_blocks'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:251:in `block in execute'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:251:in `each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:251:in `execute'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:195:in `block in invoke_with_call_chain'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:188:in `invoke_with_call_chain'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:181:in `invoke'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/sprockets-rails-3.2.1/lib/sprockets/rails/task.rb:62:in `block (2 levels) in define'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:251:in `block in execute'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:251:in `each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:251:in `execute'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:195:in `block in invoke_with_call_chain'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:188:in `invoke_with_call_chain'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:217:in `block in invoke_prerequisites'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:215:in `each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:215:in `invoke_prerequisites'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:194:in `block in invoke_with_call_chain'
/home/user/.rbenv/versions/2.3.5/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:188:in `invoke_with_call_chain'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/task.rb:181:in `invoke'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:160:in `invoke_task'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:116:in `each'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:116:in `block in top_level'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:125:in `run_with_threads'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:110:in `top_level'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:83:in `block in run'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:186:in `standard_exception_handling'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/lib/rake/application.rb:80:in `run'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/rake-12.3.0/exe/rake:27:in `<top (required)>'
/home/user/.rbenv/versions/2.3.5/bin/rake:22:in `load'
/home/user/.rbenv/versions/2.3.5/bin/rake:22:in `<top (required)>'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/cli/exec.rb:75:in `load'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/cli/exec.rb:75:in `kernel_load'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/cli/exec.rb:28:in `run'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/cli.rb:424:in `exec'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/cli.rb:27:in `dispatch'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/cli.rb:18:in `start'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/exe/bundle:30:in `block in <top (required)>'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/lib/bundler/friendly_errors.rb:122:in `with_friendly_errors'
/home/user/.rbenv/versions/2.3.5/lib/ruby/gems/2.3.0/gems/bundler-1.16.1/exe/bundle:22:in `<top (required)>'
/home/user/.rbenv/versions/2.3.5/bin/bundle:22:in `load'
/home/user/.rbenv/versions/2.3.5/bin/bundle:22:in `<main>'
Tasks: TOP => environment

I had to take it back to version 5.0.1 and no error is raised.

Please release a new version with support for redis-store 1.3.0

The gemspec has already been udpated by 622174a, we just need to cut a release. Thanks.

`exist?` method returns `ArgumentError`

successfully write.
However, cannot read!

[37] pry(main)> redis.write('foo', 'bar')
=> "OK"
[48] pry(main)> redis.exist?('foo')
ArgumentError: wrong number of arguments (given 2, expected 1)
from /path-to-redis.rb:787:in `get'
redis.read('foo')
ArgumentError: wrong number of arguments (given 2, expected 1)
from /path-to-redis.rb:787:in `get'

Certainly, I set value on Redis

pry(main)> redis = Redis.new host: redis_servers, port: 6379, db: 1
=> #<Redis client v3.2.1 for redis://localhost:6379/1>
[46] pry(main)> redis.get('foo')
=> "bar"

Requesting a new release to fix Rails 6 deprecation warning

Hey there! 😺

I was wondering if there could possibly be a new release of this lovely little gem? Possibly v5.3.0 or v.5.2.1. Our Rails 6.0.3.6 application has the following deprecation warning (from the latest release; v5.2.0):

/{...}/.rvm/gems/ruby-2.7.1@{...}/gems/redis-activesupport-5.2.0/lib/active_support/cache/redis_store.rb:85:
warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call

I noticed this has since been updated on master (master code link versus current v5.2.0 release code link).

ActiveSupport limited to v3, won't use v4

e2c87c4#diff-ba4a050cd1468223b5f52ec47d6f9edaR23

irb(main):004:0> Gem::Dependency.new('', '~> 3').match?('', '3.5')
=> true
irb(main):005:0> Gem::Dependency.new('', '~> 3').match?('', '4.5')
=> false

Unfortunately, the ~> operator doesn't really work with single digits as "any version". This means Rails 4 applications, which require an AS4 gem, can't use this gem past v4.1.1. I'm pretty sure I'd recommend a constraint like >= 3, < 5 instead.

Release new gem version

Given that

We are no longer accepting new features for this gem, only pull requests for security and compatibility fixes will be accepted.

that maybe not something you planned to do, but could you please release the current master as 5.0.5? It has a fix for TypeError: can't dup NilClass error and I know I can use

gem 'redis-activesupport', github: 'redis-store/redis-activesupport

in my Gemfile, but I prefer to keep the number of github gems to a minimum.

Use dup addresses to create connections on connection pools

If for some reason you modify the addresses variable in other place of your code, for example if you use it to setup the cache_store on Rails and Redis config on Sidekiq workers, and in both cases you're setting up a connection pool to Redis, because we're in a thread context a Sidekiq worker.

You could end mangling the addresses between both connection pools.

Update

This is only needed from connection_pool > 2.0.0 were the the connections are created as needed. I can see the development dependency is connection_pool ~> 1.2.0 so I wasn't able to create a test to reproduce the bug.

Should I provide a patch without a test or bump the connection_pool development dependency and provide a proper patch

NoMethodError - undefined method `size' for #<Redis::Future:0x007f87b1fa1d48>:

Sorry to bother you.

When I use jbuilder_cache_multi gem, I encountered the following error.

NoMethodError - undefined method `size' for #<Redis::Future:0x007f87b1fa1d48>:
  redis-store (1.1.7) lib/redis/store/marshalling.rb:41:in `unmarshal?'
  redis-store (1.1.7) lib/redis/store/marshalling.rb:33:in `_unmarshal'
  redis-store (1.1.7) lib/redis/store/marshalling.rb:17:in `get'
  redis-store (1.1.7) lib/redis/store/namespace.rb:21:in `block in get'
  redis-store (1.1.7) lib/redis/store/namespace.rb:74:in `namespace'
  redis-store (1.1.7) lib/redis/store/namespace.rb:21:in `get'
  redis-activesupport (4.1.5) lib/active_support/cache/redis_store.rb:230:in `block in read_entry'
  redis-activesupport (4.1.5) lib/active_support/cache/redis_store.rb:212:in `with'
  redis-activesupport (4.1.5) lib/active_support/cache/redis_store.rb:230:in `read_entry'
  activesupport (4.2.4) lib/active_support/cache.rb:558:in `block in find_cached_entry'
  activesupport (4.2.4) lib/active_support/cache.rb:547:in `block in instrument'
  activesupport (4.2.4) lib/active_support/notifications.rb:166:in `instrument'
  activesupport (4.2.4) lib/active_support/cache.rb:547:in `instrument'
  activesupport (4.2.4) lib/active_support/cache.rb:556:in `find_cached_entry'
  activesupport (4.2.4) lib/active_support/cache.rb:293:in `fetch'
  jbuilder (2.3.2) lib/jbuilder/jbuilder_template.rb:35:in `cache!'
  app/views/api/v1/shared/_user.json.jbuilder:7:in `_app_views_api_v__shared__user_json_jbuilder__1877584392314435341_70110396043520'

And redis/redis-rb#339

Why the fetch_multi method to use multi command?
Why not mset command?
If it using mset command, I think I would not encounter this problem.

Add License information to Gemspec

This will make it show up on rubygems.org. I'm doing due diligence on our gems and need to find out the licenses for all the gems. Having it show up on rubygems.org cuts out the step of having to go to the github repo.

Update redis-store dependency version (CVE-2017-1000248)

Hello,

With the arrival of GitHub vulnerabilities alerts, I found out by digging from redis-rails that the version 1.3.0 of redis-store used as dependency in this gem is vulnerable (CVE-2017-1000248).

I think it would be preferable to update that dependency to the latest non-breakable version.
I will try to send a PR this week about that!

delete_matched and Rails fragment caching

I'm having a problem using Rails' expire_fragment method and the RedisStore. Initially I tried calling expire_fragment using a regex as a parameter (as per the rails docs):

expire_fragment(/foo/)

and I got this message back:

Regexps aren't supported, please use string with wildcards.

So I tried:

expire_fragment("*foo*")

But it didn't work. All the keys containing foo were still there. I was looking into the expire_fragment method in the Rails source. Here's the relevant part:

if key.is_a?(Regexp)
  cache_store.delete_matched(key, options)
else
  cache_store.delete(key, options)
end

So if I pass this method a string, Rails thinks I'm giving it a key and calls the delete method that deletes keys by exact match. But obviously there's no *foo* key on redis so expiring fails.

I'm open to give this issue a try and open a PR but all the solutions I thought have drawbacks and I couldn't decide which way to go. I was hoping the maintainers you could point me in the right direction. I thought of:

Accept a regex and call source on it. We could then call expire_fragment(/*foo*/), Regex#source would give us *foo* and we'd use that as a matcher. This feels hacky and very confusing to me, because we'd be accepting a (potentially invalid) regex and not using it as such.
Overload delete to check if there are wildcards in the key. If so, call delete_matched with the key as a matcher. Otherwise, call super. Potential problem is, what if I actually have a *foo* key I want to delete?
Implementing something similar to #2 upstream. I doubt the Rails team would accept a PR with store-specific code though.

Of course I'm open to other suggestions. LMK what you think!

Client option for store creation is setting @data to a Redis client, not a Redis store

Hello,

I was attempting to memoize our Redis client and re-use it to create future ActiveSupport::Cache::RedisStore instances, but realized quickly that the implementation isn't quite right.

Referencing:
https://github.com/redis-store/redis-activesupport/blob/master/lib/active_support/cache/redis_store.rb#L69

The initializer is setting @data to the Redis client which is expected to be a Redis::Store or connection pool. This could just purely be a documentation issue, but the test itself is a bit misleading.

Side-problem, maybe someone has insight into, I don't see a way of creating a Redis::Store with an existing Redis client, so either way, it's not very useful.

`Rails.cache.increment` does not work as documented

Ran into a really weird issue today while trying to use Rails.cache.increment through this gem. I know from #96 y'all are sunsetting support for this gem, but this might represent an incompatibility with Rails that's worth fixing, and I thought I'd write about this in case someone else runs into the same issue.

The call to Rails.cache.increment('some-key') works as one might expect it to, incrementing a key in Redis. From a cold cache, if I call Rails.cache.increment('some-key') when I look at 'some-key' in Redis I see "1", which is perfectly sensible. The problem is that Rails's cache does not store anything directly like that; it instead stores a marshaled ActiveSupport::Cache::Entry object. So if I later try to retrieve the key with Rails.cache.fetch or Rails.cache.read, I get an error incompatible marshal file format (can't be read)\n\tformat version 4.8 required; 49.48 given. I also get similar marshal errors if I try to increment a key after writing it explicitly using Rails.cache.

Solution would be to marshal these the same way that ActiveSupport::Cache::Store does, or just make it clearer in the documentation that this method cannot be mixed with regular Rails cache reads/writes.

Potentially ignoring all or certain redis command errors

Hey friends! Long time user of this gem and we recently had to move our redis sentinel setup over to redis cluster. Since redis-rb has no support for redis cluster, we ended up using corvus to proxy between redis-rb and redis cluster. In the past :raise_errors has been great for preventing requests from failing during a redis blip, but now that we're using a proxy, we get a new Redis::CommandError of ERR Proxy error from corvus if redis cluster is down. If you're open to allowing me to adding support for this problem in this gem, I think 1 of the 2 approaches would work:

Rescue Redis::CommandErrors and only raise if :raise_errors is disabled. This is an easy change but has negative side effects since a Redis::CommandError is something that should probably not be swallowed.
Add a whitelist of Redis::CommandErrors that can safely be ignored as an argument. By default, no errors are ignored, but you could do something like:

{ :raise_errors => false, :ignored_command_errors => ["ERR Proxy error"] }

Of the two options, I think (2) is far more maintainable. I have a branch for (2) ready to open as a PR, but I wanted to check to see if this is something you'd be interested in accepting. Thanks!

version bump

The latest pull request, fixing the issue with redis/activesupport/version, needs a new version bump. Thank you for the software :-)

Test against Ruby 2.4

rescue Errno::EHOSTUNREACH

This is more of a question than an issue.

Currently, the connection errors Errno::ECONNREFUSED and Redis::CannotConnectError are rescued when trying to access redis, example here. This morning our hosting service moved our redis server to another hypervisor (and we missed the email notification) which caused us some downtime with the error Errno::EHOSTUNREACH being raised from within the redis gem. Since we use redis for caching it would have been nice if those errors were rescued and the site continued running without caching. Is there any reason we wouldn't also want to rescue Errno::EHOSTUNREACH in addition to Errno::ECONNREFUSED? I'm happy to open a pull request if it would be accepted.

I'm using:

redis-activesupport 3.2.5
redis 2.2.0
redis-store 1.1.4
redis-rails 3.2.4

From what I can tell being on the latest version of these gems wouldn't have made a difference in Errno::EHOSTUNREACH errors going unrescued.

Version bump

Any reason the version hasn't been bumped since 2013? There's a bunch of commits since then that I need having to do with connection pooling

Inconsistant Key marshalling for increment and read/write

I'm using a Hash object as my key, and cannot read a key after incrementing. It looks like the Hash key is being serialized differently in the increment function. This is with Rails 4.1.6 and Redis-Store 4.0

See below:

Rails.cache.increment({hkey: 'test'})
# => 1
redis-cli:  KEYS *
# "{:hkey=>\"test\"}"
Rails.cache.read({hkey: 'test'})
# => nil
Rails.cache.write({hkey: test}, 10)
# => OK
redis-cli: KEYS *
#  "hkey=test"
#  "{:hkey=>\"test\"}"
Rails.cache.increment({hkey: 'test'})
# => 2
Rails.cache.read({hkey: 'test'})
# => 10

Cache key on 5.2.0.rc1

Steps to reproduce

<% cache @group %>

No longer includes the updated_at in the cache_key in 5.2.0.rc1

Expected behavior

This is an example of a generated key in 5.2.0.beta2
groups/show:b25ce2a718e61c4980803b1b01b4d28a/groups/3-20180219205350119722

Actual behavior

The same command in 5.2.0.rc1 does not include the updated_at and therefore is stale even though the record is updated
groups/show:d8f81a8f744c2141d7eb53baca7d32fa/groups/3

I have not enabled this line in the initializers/new_framework_defaults_5_2.rb file
# Rails.application.config.active_record.cache_versioning = true

DEPRECATION WARNING: `namespaced_key` is deprecated and will be removed from Rails 5.1.

DEPRECATION WARNING: `namespaced_key` is deprecated and will be removed from Rails 5.1.
Please use `normalize_key` which will return a fully resolved key.
 (called from _app_views_layouts__actions_html_slim__1097243744115237450_70204946685240 at

      def read_multi(*names)
        options = names.extract_options!
        keys = names.map{|name| namespaced_key(name, options)}
        values = with { |c| c.mget(*keys) }
        values.map! { |v| v.is_a?(ActiveSupport::Cache::Entry) ? v.value : v }

        # Remove the options hash before mapping keys to values
        names.extract_options!

        result = Hash[keys.zip(values)]
        result.reject!{ |k,v| v.nil? }
        result
      end

can be replaced with:

      def read_multi(*names)
        options = names.extract_options!
        keys = names.map{|name| normalize_key(name, options)}
        values = with { |c| c.mget(*keys) }
        values.map! { |v| v.is_a?(ActiveSupport::Cache::Entry) ? v.value : v }

        # Remove the options hash before mapping keys to values
        names.extract_options!

        result = Hash[keys.zip(values)]
        result.reject!{ |k,v| v.nil? }
        result
      end

👍 #59

How to inject underlying Redis object, as in the case of connection pooling

Hi there.

When using redis-rb directly, I can do something like:

redis = ConnectionPool::Wrapper.new(size: 5, timeout: 5) { Redis.new(url: ...) }

I've also issued explicit redis.quit to keep connection usage low.

Is it possible to do something similar with redis-store/redis-activesupport?

Thanks.

Cache versionning in Rails 6

Dear maintainers,

I am currently testing the upgrade of a Rails app from 5.2.3 to 6.0.0.rc1. In the official migration guide, there is a mention of this command to check that everything is working with the new gem loader:

bin/rails zeitwerk:check

I ran it on my app which happens to have the following configuration for development and production environments:

# config/environments/*.rb

if ENV['DISABLE_CACHE'] == 'true'
  config.cache_store = :null_store
else
  config.cache_store = :redis_store, 'redis://localhost:6379/0/cache', { expires_in: 1.hour }
end

The redis_store is available thanks to the latest redis-rails gem added to my Gemfile.

Here is the error message that zeitwerk:check gives after a bundle update rails to 6.0.0.rc1:

rails aborted!

You're using a cache store that doesn't support native cache versioning.
Your best option is to upgrade to a newer version of ActiveSupport::Cache::RedisStore
that supports cache versioning (ActiveSupport::Cache::RedisStore.supports_cache_versioning? #=> true).

Next best, switch to a different cache store that does support cache versioning:
https://guides.rubyonrails.org/caching_with_rails.html#cache-stores.

To keep using the current cache store, you can turn off cache versioning entirely:

    config.active_record.cache_versioning = false

/Users/seb/code/lewagon/www/config/environment.rb:5:in `<top (required)>'
bin/rails:4:in `require'
bin/rails:4:in `<main>'
Tasks: TOP => zeitwerk:check => environment
(See full trace by running task with --trace)

Adding the suggested line to config/application.rb allows the command to run successfully but I wonder if there is so plan to support this Rails 6 feature?

Thank you very much!

`fetch_multi` with nested keys (digests) not working

We are using the jbuilder_cache_multi gem and wanted to transition from a memcache based store to a Redis store. It looks like the current implementation of fetch_multi on the Redis store does not work with nested keys.

Here is the relevant snippet in jbuilder_cache_multi. What happens is that the keys passed to cache.fetch_multi have the following format:

[<Object>, "<digest>"]

This leads to the following structure of *names in fetch_multi:

[
  [#<User id: 1>, "18fa3886e874288b209640bfccb619be"],
  [#<User id: 2>, "18fa3886e874288b209640bfccb619be"],
  [#<User id: 3>, "18fa3886e874288b209640bfccb619be"]
]

We tracked the issue down to this line of the current fetch_multi implementation:

names.inject({}) do |memo, (name, _)|

This drops the digest part. When a key is missing only #<User id: 1> will be yielded to the block passed to fetch_multi.

Something similar has been brought up in #50

delete_matched only checks for regexps when a prefix is given

See

redis-activesupport/lib/active_support/cache/redis_store.rb

Line 217 in e81c80e

    
           raise "Regexps aren't supported, please use string with wildcards." if pattern.is_a?(Regexp)

Unless I'm missing something regexps aren't supported without prefixes either, right?

Still getting errors even with raise_errors: false

Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) excluded from capture: Not configured to send/capture in environment 'development'

Redis::CannotConnectError (Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)):

I'm still getting this even when I've configured it with raise_errors: false. Is this an expected behavior? I'm expecting it to normally continue the code without errors.

➜  PROJECT git:(search) ✗ grep redis Gemfile.lock
    redis (4.0.1)
    redis-actionpack (5.0.2)
      redis-rack (>= 1, < 3)
      redis-store (>= 1.1.0, < 2)
    redis-activesupport (5.0.5)
      redis-store (>= 1.3, < 2)
    redis-rack (2.0.4)
      redis-store (>= 1.2, < 2)
    redis-rails (5.0.2)
      redis-actionpack (>= 5.0, < 6)
      redis-activesupport (>= 5.0, < 6)
      redis-store (>= 1.2, < 2)
    redis-store (1.5.0)
      redis (>= 2.2, < 5)
  redis-rails

Would you mind release `redis-actionpack` to rubygems.org #

Would you mind release redis-actionpack as a minor release to rubygems.org so that we could use redis-store 1.4.0?

Thanks and Best Regards.

Nice one!

Nice one @radar ! This library will be shared in RedisWeekly ( http://redisweekly.com ) tomorrow 🚀!

nil value is not being sent back in read_multi

cache = RedisStore.new
cache.write(:test, nil)

expect(cache.read_multi([:test0, :test, :test1])).to eq ({test: nil}) # fails
expect(cache.read_multi([:test0, :test, :test1])).to_not eq ({}) # fails

found when redis store fails for test - https://github.com/justinweiss/bulk_cache_fetcher/blob/master/test/bulk_cache_fetcher_test.rb#L130-L137

Inconsistent Key marshalling for read_multi/fetch_multi

If you try to pass Array/Hash like keys, or any option, specially namespace, to read_multi or fetch_multi, it will throw "NoMethodError: undefined method `match' for ...".

It's similar to #23

Upgrade requirement of redis-store

Version: 1.3.0
Advisory: CVE-2017-1000248
Criticality: Unknown
URL: redis-store/redis-store@ce13252
Title: Unsafe objects can be loaded from Redis
Solution: upgrade to >= 1.4.0

Bundler could not find compatible versions for gem "redis-store":
  In Gemfile:
    redis-store (>= 1.4.0)

    redis-rails was resolved to 5.0.2, which depends on
      redis-activesupport (< 6, >= 5.0) was resolved to 5.0.3, which depends on
        redis-store (~> 1.3.0)

Compatibility with Rails 4

Hi guys. There is some compatibility issue regarding master branch and 5.0.2 release version.

I'm trying to use master branch, which contains changes from jbuilder_multi_cache compatibility, but bundle install fails. It happens, because 'redis-activesupportdepends onredis-rails 5.0.1, which depends on redis-actionpack 5.0.1, which depends on redis-rack 2.0.0, which depends on rack ~> 2.0.0. But meanwhile Rails 4 depends on rake ~> 1.6.0. So the new version of redis-activesupport` works with Rails 5+ version only.

I'm also described this problem in #78.

redis-store / redis-activesupport Goto Github PK

redis-activesupport's Introduction

Redis stores for Ruby frameworks

Redis Installation

Option 1: Homebrew

Option 2: From Source

Running tests

Contributors

Versioning

Status

Copyright

redis-activesupport's People

Contributors

Stargazers

Watchers

Forkers

redis-activesupport's Issues

Update

Steps to reproduce

Expected behavior

Actual behavior

Recommend Projects

Recommend Topics

Recommend Org