Disappearing Associations

Jon_Wood · December 21, 2007, 5:24pm

Hi,

I’m using a belongs_to association to link two models, and having some
very odd problems with it.

When I first view the page, all is well, and the associated object is
loaded, however on the second view it crashes with a NoMethodError on
the association (full trace is at the bottom of this e-mail).

It looks like my model is losing it’s association on the second run,
since the method no longer exists, if I call
@model.class.belongs_to :associated_model it will run successfully
every time.

This looks similar to bug 6720 in Trac, although that bug was
apparently closed 10 months ago.
Jon

Backtrace follows:

vendor/rails/activerecord/lib/active_record/attribute_methods.rb:
205:in method_missing' vendor/rails/activerecord/lib/active_record/associations/ association_proxy.rb:125:insend’
vendor/rails/activerecord/lib/active_record/associations/
association_proxy.rb:125:in method_missing' app/views/servers/index.rhtml:25:in_run_erb_47app47views47servers47index46rhtml’
app/views/servers/index.rhtml:18:in each' app/views/servers/index.rhtml:18:in_run_erb_47app47views47servers47index46rhtml’
vendor/rails/actionpack/lib/action_view/base.rb:637:in send' vendor/rails/actionpack/lib/action_view/base.rb:637:incompile_and_render_template’
vendor/rails/actionpack/lib/action_view/base.rb:365:in
render_template' vendor/rails/actionpack/lib/action_view/base.rb:316:inrender_file’
vendor/rails/actionpack/lib/action_controller/base.rb:1100:in
render_for_file' vendor/rails/actionpack/lib/action_controller/base.rb:836:inrender_with_no_layout’
vendor/rails/actionpack/lib/action_controller/layout.rb:262:in
render_without_benchmark' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:inrender’
/usr/lib/ruby/1.8/benchmark.rb:293:in measure' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:inrender’
vendor/rails/actionpack/lib/action_controller/base.rb:1153:in
default_render' vendor/rails/actionpack/lib/action_controller/base.rb:1159:inperform_action_without_filters’
vendor/rails/actionpack/lib/action_controller/filters.rb:697:in
call_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:689:inperform_action_without_benchmark’
vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in
perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:293:inmeasure’
vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in
perform_action_without_rescue' vendor/rails/actionpack/lib/action_controller/rescue.rb:199:inperform_action_without_caching’
vendor/rails/actionpack/lib/action_controller/caching.rb:678:in
perform_action' vendor/rails/activerecord/lib/active_record/connection_adapters/ abstract/query_cache.rb:33:incache’
vendor/rails/activerecord/lib/active_record/query_cache.rb:8:in
cache' vendor/rails/actionpack/lib/action_controller/caching.rb:677:inperform_action’
vendor/rails/actionpack/lib/action_controller/base.rb:524:in send' vendor/rails/actionpack/lib/action_controller/base.rb:524:inprocess_without_filters’
vendor/rails/actionpack/lib/action_controller/filters.rb:685:in
process_without_session_management_support' vendor/rails/actionpack/lib/action_controller/session_management.rb: 123:inprocess’
vendor/rails/actionpack/lib/action_controller/base.rb:388:in process' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:171:inhandle_request’
vendor/rails/actionpack/lib/action_controller/dispatcher.rb:115:in
dispatch' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:126:indispatch_cgi’
vendor/rails/actionpack/lib/action_controller/dispatcher.rb:9:in
dispatch' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel/rails.rb:76:inprocess’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel/rails.rb:74:in
synchronize' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel/rails.rb:74:inprocess’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:159:in
process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:158:ineach’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:158:in
process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:285:inrun’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:285:in
initialize' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:285:innew’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:285:in run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:268:ininitialize’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:268:in new' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel.rb:268:inrun’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel/configurator.rb:
282:in run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel/configurator.rb: 281:ineach’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel/configurator.rb:
281:in run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/mongrel_rails:128:inrun’
/usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/lib/mongrel/command.rb:
212:in run' /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.2/bin/mongrel_rails:281 vendor/rails/activesupport/lib/active_support/dependencies.rb:489:inload’
vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
load' vendor/rails/activesupport/lib/active_support/dependencies.rb:342:innew_constants_in’
vendor/rails/activesupport/lib/active_support/dependencies.rb:489:in
load' vendor/rails/railties/lib/commands/servers/mongrel.rb:64 /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:ingem_original_require’
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in
require' vendor/rails/activesupport/lib/active_support/dependencies.rb:496:inrequire’
vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in
new_constants_in' vendor/rails/activesupport/lib/active_support/dependencies.rb:496:inrequire’
vendor/rails/railties/lib/commands/server.rb:39
script/server:3:in `require’
script/server:3

Jon_Wood · December 21, 2007, 6:48pm

On 21 Dec 2007, at 16:23, Jon Wood wrote:

Hi,

I’m using a belongs_to association to link two models, and having some
very odd problems with it.

When I first view the page, all is well, and the associated object is
loaded, however on the second view it crashes with a NoMethodError on
the association (full trace is at the bottom of this e-mail).

I’ll bet you a beer that this stops happening in production mode or if
you turn on class caching.
Whenever I’ve seen this it’s been due to a dependencies screwup (which
include plugins that aren’t reloaded referencing things that are,
using require when you should be letting Rails autoload things or
using require_dependency and generally things of that nature.

Fred

Jon_Wood · December 24, 2007, 10:59am

It does indeed disappear when caching is turned on, however that seems
like a hack at best, thanks for the pointer though - I guess it’s time
to audit my code for requires

Thanks for the help,

Jon

On Dec 21, 5:47 pm, Frederick C. [email protected]

Jon_Wood · December 24, 2007, 11:09am

Another update - I’ve just checked, and I’m not requiring anything
from my application, and despite removing all the plugins I have
installed I’m still getting the same symptoms.

I’m using a polymorphic association on the model causing this problem

could it be related to that?

Jon

Jon_Wood · December 24, 2007, 11:20am

Sorry to spam the list, but I’m hoping somebody will be able to piece
together the clues.

My latest discovery is that whilst @server.details.cabinet.datacenter
doesn’t work, SpaceCabinet.find(@server.details.cabinet_id).datacenter
does, so it appears it’s the individual model object that is having
problems, rather then all models of that type.

I’m feeling a little like I’m falling down the rabbit hole now!

Jon

Jon_Wood · December 24, 2007, 12:45pm

On Dec 24, 11:15 am, Frederick C. [email protected]
wrote:

it didn’t then you’d get a problem)

Nope - I’m not using the session at all at the moment. It’s all just
CRUD at the moment, other then the fact it’s using polymorphics.

I’ve hacked in doing an extra find for now, although I’ll have to find
a better solution sometime, or I’m going to end up bringing down our
database server once this goes live! Apologies for you having to work
without source code - I’d provide more, but I’ve only just started
working here, and I don’t know what the policy on posting code to
mailing lists is.

Happy Holidays, and thanks for your help,

Jon

Jon_Wood · December 26, 2007, 1:37am

Any luck I am experiencing the thing.
I noticed that the id attribute is not returned with the association
is called
All works fine in the console but no luck. not even from a debug
console.

Jon_Wood · December 26, 2007, 8:05am

Joshua Hoskins wrote:

Any luck I am experiencing the thing.
I noticed that the id attribute is not returned with the association
is called
All works fine in the console but no luck. not even from a debug
console.

Try adding the require statement in the models.

I also got the same problem. But when i loaded the files using require
statement, it worked fine in development mode.

Add the require statements according to the associations in the model.

Karthik.

Jon_Wood · December 27, 2007, 11:26am

Thanks Karthik, I think that’s done the trick - I was so busy trying
to get rid of require statements I didn’t think to add any!

Jon

On Dec 26, 7:05 am, Karthi kn [email protected]

Jon_Wood · December 24, 2007, 12:15pm

On 24 Dec 2007, at 10:20, Jon Wood wrote:

Sorry to spam the list, but I’m hoping somebody will be able to piece
together the clues.

My latest discovery is that whilst @server.details.cabinet.datacenter
doesn’t work, SpaceCabinet.find(@server.details.cabinet_id).datacenter
does, so it appears it’s the individual model object that is having
problems, rather then all models of that type.

I’m feeling a little like I’m falling down the rabbit hole now!

It’s even harder if you’ve doing it blind
If you are persisting an object accross requests that could cause the
problem (normally the magic reload stuff would clear that for you, if
it didn’t then you’d get a problem)

Fred