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

Add ActiveSupport interface? #2

Open
findchris opened this issue Oct 21, 2014 · 5 comments
Open

Add ActiveSupport interface? #2

findchris opened this issue Oct 21, 2014 · 5 comments

Comments

@findchris
Copy link

Nice work with this project. I came to it after looking into why something as ostensibly simple as ActiveSupport::Cache::MemoryStore is slower than I expected, and figuring someone had written something better (and you have!). So thanks for that.

The MemoryStore is a ActiveSupport::Cache::Store, the primary benefit of which is a cache backend-agnostic interface. Would you be interested in making fast_cache inherit from ActiveSupport::Cache::Store, so that it can seamlessly replace MemoryStore? I understand if you want to keep this implementation ActiveSupport-free, but maybe a new project such as fast_cache_store?

Would like to hear your thoughts.

@ssimeonov
Copy link
Contributor

Have you taken a close look at the API ActiveSupport::Cache::Store and its expectations, especially around size-based constraints?

@findchris
Copy link
Author

What sized-based constraints?

@ssimeonov
Copy link
Contributor

For example, the handling of a universal option such as :compress_threshold. See http://api.rubyonrails.org/classes/ActiveSupport/Cache.html

@findchris
Copy link
Author

So are you saying you're against the idea of a fast_cache-backed Store because of the overhead/bloat of the base class?

@ssimeonov
Copy link
Contributor

Not at all.

I'm saying that some interesting choices have to be made with respect to how to satisfy the so-called "universal" requirements for all stores in a manner that doesn't throw away the performance benefits of fast_cache. I did not have a strong gut sense on this (or a need for it), which is the only reason why I did not create a separate project as you suggest.

If you want to go ahead and do this, I'd be happy to do a code review.

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

No branches or pull requests

2 participants