I have an ActiveResource based application (referred to as client) that interfaces with an API application(referred to as api).
I have a model instance, I update the instance through a form, form puts to the client with a simple controller like this:
def update
@current_user.update_attributes(:psset => params[:permissions])
end
Instead of going to the update controller on the api though, the update controller POSTS to the create controller on the api, not the update, i.e. triggers POST to /users instead PUT to /users/:id. the form always goes to this controller, so the form posts to the client properly.
The most maddening part is that running the command
@current_user.update_attributes(:psset => params[:permissions])
from within pry with the same environment for the same resource will PUT to /users/:id on the api.
So something in that update controller when calling update_attributes is catching that as trying to register a new resource and goes to create on the api.
I'm mystified as to why I can't update from a controller, but can from a command line instance. This is a first in this situation, with this controller, so there must be something I am doing at some point that triggers a new resource, but can't figure out what. As usual, I'll attempt to fill in more specific code based on questions. I know I'm probably just missing something dumb, but what?
EDIT: requested relevant routes
api:
resources :users do #, :only => [:index, :show, :create, :destroy]
collection do
end
end
client:
resources :user, :only => [ :show, :update, :destroy ]
I'm realizing that earlier I made some distinction between user/users in routing and controllers on the client side that looking at I'm not sure is the most efficient method, now hmmm, but it has not been an issue until now. If there is a better way to make that distinction in routes (user/users) without separate controllers I'd like to now, it is just a persnickety user apprehension feature I noticed.
After tweaking routes around and whatnot, the issue persist. I post properly to the client route, that client route goes to create a new resource, not update the existing one (even though it uses params it would use for updating).
UGH, found an answer sort of. I started using the cached_resource gem with this client, and I recently turned it on for all the models. Turned it off for the user model, problem gone. Putting caching solutions to the future once more.
Logic of activeresource update_attributes is next
File activeresource/lib/active_resource/base.rb, line 1306
def update_attributes(attributes) load(attributes, false) && save end
# File activeresource/lib/active_resource/base.rb, line 1147
def save
new? ? create : update
end
so it can post or put depends on result of new? method here is that method (it depends on persisted)
def new?
!persisted?
end
Explanation is here http://api.rubyonrails.org/classes/ActiveResource/Base.html#method-i-persisted-3F