Expiration of controller action from Sweeper does not work - ruby-on-rails

Having a controller handling rendering of large XML feeds
module Spree
class FeedsController < Spree::StoreController
...
caches_action :products_out
cache_sweeper FeedSweeper
# XML feed in format of `xxxxxxx.com'
def products_out
#products = Product.all
respond_to do |format|
format.xml
end
end
end
Bellow is the corresponding sweeper's sublass:
module Spree
class FeedSweeper< ActionController::Caching::Sweeper
observe Product
def after_update(product)
# cache_configured? is nil, #controller is nil here, why ?
expire_action(:controller => :feeds,
:action => :products_out,
:format => :xml)
end
end
Above Spree::FeedSweeper is called when Spree::Product gets updated, however it seems expire_action silently dies and cache won't get invalidated.
Can somebody explain the issue ? Even better suggest some solution ?
Thanks.

Which Rails version are you using? expire_action seems to be deprecated after Rails 3.2.14.
Maybe you can try to find out the key then directly clear it with Rails.cache.delete(key).

Related

Automatically vote up item by the user that created it [Rails 3.2.11] [acts_as_votable] [devise]

I'm using the acts_as_votable and devise gems in Rails 3.2.11 and I'm trying to automatically have the user who created an item vote it up after it's created. Sounds simple, right? I have a vote_up method in my controller and I've tried this:
after_filter :vote_up, :only => :create
Yet alas, it does nothing. I know the vote_up method isn't broken, because it works perfectly whenever it's called from the view.
Any ideas?
Edit: The vote_up method in my controller:
def vote_up
#skill_relationship = SkillRelationship.find(params[:id])
if current_user.voted_up_on? #skill_relationship then
#skill_relationship.unliked_by :voter => current_user
else
#skill_relationship.liked_by current_user
end
respond_to do |format|
format.js { render :action => "vote" }
end
end
I would also be OK with just running the line #skill_relationship.unliked_by :voter => current_user or something similar directly in my create method (which I've also tried, to no avail).
This is from quite some time ago, but if anyone else stumbles upon it, just add something like this after the model is saved in the create action:
current_user.likes #skill_relationship

Simple respond_with in rails that avoids 204 from PUT

I want to PUT to rails and avoid getting a 204. I am using this pattern:
class SomeController < ApplicationController
respond_to :json
def update
# ...
respond_with(some_object)
end
end
However, when I do a put to update, I get a 204 back. I realize this is completely valid etc, but I explicitly want the content back. I can override it to some extent like this:
def update
respond_with(some_object) do |format|
format.json{render json: some_object}
end
end
but this seems a bit too hands-on for rails. Is there any more idiomatic way of avoiding a 204 and requesting the full content to be sent back? This is Rails 3.2.
In summary: I want maximally idiomatic rails that avoids a 204.
I made a custom responder which always returns my JSON encoded resource even on PUT/POST.
I put this file in lib/responders/json_responder.rb. Your /lib dir should be autoloaded.
module Responders::JsonResponder
protected
# simply render the resource even on POST instead of redirecting for ajax
def api_behavior(error)
if post?
display resource, :status => :created
# render resource instead of 204 no content
elsif put?
display resource, :status => :ok
else
super
end
end
end
Now, explicitly modify the controller which requires this behavior, or place it in the application controller.
class ApplicationController < ActionController::Base
protect_from_forgery
responders :json
end
You should now get JSON encoded resources back on PUT.
As a less invasive alternative, you can pass a json: option to the respond_with method invocation inside your controller update action, like this:
def update
# ...
respond_with some_object, json: some_object
end
Granted it seems a bit unDRY having to repeat the object twice in the arguments, but it'll give you what you want, the json representation of the object in the response of a PUT request, and you don't need to use the render json: way, which won't give you the benefits of responders.
However, if you have a lot of controllers with this situation, then customizing the responders, as jpfuentes2 showed in the accepted anwser, is the way to go. But for a quick single case, this alternative may be easier.
Source: https://github.com/plataformatec/responders/pull/115#issuecomment-72517532
This behavior seems intentional to fall in line with the HTTP spec, and "ideally" you should be firing off an additional GET request to see the results. However, I agree in the real world I'd rather have it return the JSON.
#jpfuentes2's solution above should do the trick (it's very similar to the pull request below), but I'm hesitant to apply anything that's patching rails internals, as it could be a real pain to upgrade between major versions, especially if you don't have tests for it (and let's face it, developers often skimp on controller tests).
References
https://github.com/rails/rails/issues/9862
https://github.com/rails/rails/pull/9887
Just to clarify, you do not need the responders gem to do this... You can just do:
config/initializers/responder_with_put_content.rb
class ResponderWithPutContent < ActionController::Responder
def api_behavior(*args, &block)
if put?
display resource, :status => :ok
else
super
end
end
end
and then either (for all updates actions to be affected):
class ApplicationController < ActionController::Base
def self.responder
ResponderWithPutContent
end
end
or in your action:
def update
foo = Foo.find(params[:id])
foo.update_attributes(params[:foo])
respond_with foo, responder: ResponderWithPutContent
end
What's wrong with simply doing:
def update
some_object = SomeObject.update()
render json: some_object
end
Not a big fan of this behavior. To get around it, I had to avoid using the respond_with method:
class SomeController < ApplicationController
respond_to :json
def update
# ...
respond_to do |format|
format.json { render(json: some_object, status: 200) }
end
end
end

expire_action from model

I have an offline rake job that updates my models. When that happens, I want to expire the :show action for that model.
# in lib/models/my_model.rb
after_update :expire_cache
def expire_cache
expire_action :controller => :my_models, :action => :show, :id => self
end
This doesn't work because expire_action isn't available in the model. Calling ActionController.new.expire_action gives me a lot of weird route issues, which is reasonable since none of the route logic is hooked up.
I think the common way to expire_action is with a sweeper, but that doesn't work because my model is not updated through controller actions.
NOTE: I feel like I may be using caching the wrong way since I can't find an answer to this anywhere.
You're looking for an ActionController Sweeper. You can find the official Rails documentation on how to implement them here, but likely you want something like this:
class MyModelSweeper < ActionController::Caching::Sweeper
observe MyModel
def after_update(my_model)
expire_action :controller => :my_models, :action => :show, :id => my_model
end
end

rails expire_page is not deleting the cached file

I have a controller action that has page caching, and I made a sweeper that calls expire_page with the controller and the action specified...
The controller action renders a js.erb template, so I am trying to ensure that expire_page deletes the .js file in public/javascripts, which it is not doing.
class JavascriptsController < ApplicationController
caches_page :lol
def lol
#lol = Lol.all
end
end
class LolSweeper < ActionController::Caching::Sweeper
observe Lol
def after_create(lol)
puts "lol!!!!!!!"
expire_page(:controller => "javascripts", :action => "lol", :format => 'js')
end
end
... So, I visit javascripts/lol.js and I get my template rendered.. I verified that public/javascripts/lol.js exists... I then create a new Lol record, and I see "lol!!!!!!!!!" meaning the after_create observer method is triggered, but expire_page is doing nothing...
According to RailsGuides: 'Page caching ignores all parameters.' I think I had similar problem while working on cashing .xml responses: I would write the cache for /lol.xml, but was trying to expire cache for /lol (write and expire operations can be seen in the server log). The way I made it work: I made the cache "format-agnostic" like this:
cashes_page :lol, :cache_path => Proc.new { |controller| controller.params.delete_if {|k,v| k == "format"} }
and expire in the sweeper like this:
expire_page(:controller => "javascripts", :action => "lol")
It solved my problem. Also, as a note, shouldn't your lol action be called lols? Good luck.
I tried solution form Simon's answer and it didn't work for me. The solution that worked was:
expire_page('javascripts/lol.js')

Accessing virtual attribute from JSON

My setup: Rails 2.3.10, Ruby 1.8.7
I have experimented, without success, with trying to access a virtual attribute in a model from a JSON call. Let's say I have the following models and controller code
class Product
name,
description,
price,
attr_accessor :discounted_price
end
class Price
discount
end
class ProductsController
def show
#product = Product.find(params[:id])
respond_to do |format|
format.html # show.html.erb
format.json { render :json => #product }
end
end
end
What I like is to have the JSON output also include Product.discounted_price which is calculated in real-time for each call, ie discounted_price = Price.discount * Product.price. Is there a way to accomplish this?
SOLUTION:
With the initial help from dmarkow, I figured it out, my actual scenario is more complex than the above example. I can do something like this, in the Product model, add a getter method
def discounted_price
...# do the calculation here
end
In the JSON call do this
store = Store.find(1)
store.as_json(:include => :products, :methods => :discounted_price)
You can run to_json with a :methods parameter to include the result of those method(s).
render :json => #product.to_json(:methods => :discounted_price)
Have a look at the gem RABL, as shown in this railscast:
http://railscasts.com/episodes/322-rabl?view=asciicast
RABL gives you fine grained control of the json you produce, including collections and children.

Resources