实际上，如何从Rails中的控制器调用控制器？

Question

Ok, ok, on the surface this seems like a very bad idea, and most of the time it is. It is not MVC, it creates potential weird dependencies, and it does not follow good logical separation of concerns.

Now let me explain the situation that has led me to ask this question. We have a third party api. We necessarily have to cache it for long periods of time for performance reasons. Sometimes they change their data, and we need reflect it immediately. We have given them an api endpoint to clear the cache (as we are not going to give them access to our internal cache, for a variety of reasons). I need some way to rewarm the cache. Rewarming their api call is easy. However, we have view fragment caches that are dependent on that data, and I would like to rewarm those as well.

Basically I would like to cache everything that would normally be cached during a call on this second controller. However, trying this results in timeouts on the second controller call. Is there a way to accomplish this, or an alternate method that will result in all necessary elements (including view elements that use rails fragment caching) to be cached?

Answer 1

It seems like your real problem is busting the fragment caches. Why not just use a self busting cache key. If you're caching a piece of the view with cache 'key' do... that "key" string could be updated by a model or something such as the Post.count or something. For example, in an API controller caching a list of Posts as a JSON list:

# your api controller's index action
@post_json = Rails.cache.fetch "posts-#{Post.count}-#{Post.order(:updated_at).last.updated_at}" do
  Post.all.to_json
end

Now that you have a collection of posts cached and ready to be sent as an API response and you're using a self busting cache key you won't have to worry about manually "rewarming" your cache. Whenever a new Post is created or one is updated the cache key will be different because the count and updated_at (for the most recently updated post) will be different and cause the Rails.cache.fetch method to execute the block, rewarming your cache.

With this sort of dynamic cache key you can use any method to update it that doesn't require calling a controller (which is very hard and not recommended).

Answer 2

To get around the problem of Rails maintaining a single connection, you can use a multi-threaded approach:

Thread.new do
    # do stuff here
end