Rails 2.1.2 bug in include on has_many?


#1

In my continued efforts to port my rails 1.x app to Rails 2.1.2, I keep
running into what appear to be ActiveRecord bugs.

I am using an :include on a :has_many definition:

class Request < ActiveRecord::Base
has_many :service_types, :order=>‘service_types.id ASC’,
:include=>:service_response
[…]

There’s no reason this wouldn’t be supported in Rails 2.1.2, is there?

Worked fine in Rails 1.2.6. In Rails 2.1.2, I fetch in a Request
objects, and then I try to call some_request.service_types, and I get an
exception.

Anyone run into this? Any ideas? That :include is really useful to me
for efficiency.

You have a nil object when you didn’t expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.each

/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:74:in
set_association_single_records' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:67:ineach’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:67:in
set_association_single_records' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:242:inpreload_belongs_to_association’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:219:in
each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:219:inpreload_belongs_to_association’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:40:in
send' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:40:inpreload_one_association’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:38:in
each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:38:inpreload_one_association’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:17:in
preload_associations' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:16:inpreload_associations’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:16:in
each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/association_preload.rb:16:inpreload_associations’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/base.rb:1347:in
find_every' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/base.rb:540:infind’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_collection.rb:47:in
find' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_collection.rb:308:infind_target’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_collection.rb:262:in
load_target' /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_proxy.rb:169:inmethod_missing’
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations/association_collection.rb:279:in
method_missing' app/controllers/test_controller.rb:9:inindex’


#2

On 6 Nov 2008, at 16:39, Jonathan R. wrote:

[…]

There’s no reason this wouldn’t be supported in Rails 2.1.2, is there?

It should work. :include was rewritten for rails 2.1 though.
service_type has a belongs_to :service_response ?

Fred


#3

Frederick C. wrote:

On 6 Nov 2008, at 16:39, Jonathan R. wrote:

[…]

There’s no reason this wouldn’t be supported in Rails 2.1.2, is there?

It should work. :include was rewritten for rails 2.1 though.
service_type has a belongs_to :service_response ?

Fred

It sure does.

This is annoying me highly. I’ve pared down my code to a simple
reproducible test case. And it’s still exhibiting. i can’t figure out
what I’m doing to trigger the bug, if everyone else is using :has_many,
:include without problems. Very frustrating.


#4

Jonathan is probably right. ‘Request’ is a reserved word in Rails -
see http://wiki.rubyonrails.org/rails/pages/ReservedWords

Try changing the model name to ServiceRequest or similar.

On Nov 7, 6:43 am, Jonathan R. <rails-mailing-l…@andreas-


#5

Hmm, is it possible that the fact that the model is named “Request” is
somehow triggering the bug? That’s the only thing I can figure out.

Jonathan

Jonathan R. wrote:

Frederick C. wrote:

On 6 Nov 2008, at 16:39, Jonathan R. wrote:

[…]

There’s no reason this wouldn’t be supported in Rails 2.1.2, is there?

It should work. :include was rewritten for rails 2.1 though.
service_type has a belongs_to :service_response ?

Fred

It sure does.

This is annoying me highly. I’ve pared down my code to a simple
reproducible test case. And it’s still exhibiting. i can’t figure out
what I’m doing to trigger the bug, if everyone else is using :has_many,
:include without problems. Very frustrating.


#6

Thanks a lot Chris. Sadly, I’ve got my work cut out for me, as changing
the name of the model in this fairly mature application is going to be
some work. But at least it all makes some sense now.

Is it possible to change the model name without changing the name of the
associations that point to it in other models? Or, I guess, to alias
the association name ‘request’ to an ‘actual’ association named
service_request or whatever. To give me less code that has to be
changed? Any advice as to the lowest impact way to change a model name
in a mature application with lots of code that refers to that model, and
to associations in other models that point to that model?

Odd that I got away with it in Rails 1.x, but oh well, I guess it was
really incorrect all along.

Jonathan

Chris B. wrote:

Jonathan is probably right. ‘Request’ is a reserved word in Rails -
see http://wiki.rubyonrails.org/rails/pages/ReservedWords

Try changing the model name to ServiceRequest or similar.

On Nov 7, 6:43�am, Jonathan R. <rails-mailing-l…@andreas-


#7

Hmm, just changing the model name from Request to AppRequest doesn’t
seem to have done it.

I tried to leave the (many) associations pointing to AppRequest (nee
Request) the same, but specify a :class_name and :foreign_key.

It sounds like maybe “request” as the name of an assocation, even when
not the name of the model, is a no-no too?

Man, that lengthy lengthy list of reserved words, which wasn’t really
official documentation anyway and seems to be have been discovered only
by experimentation… is leading to one of those times I’m less happy
with ruby/rails.

I’ve got a lot of refactoring to do. Changing the many association names
to this model every time they are used is not going to be fun.

Jonathan

Jonathan R. wrote:

Thanks a lot Chris. Sadly, I’ve got my work cut out for me, as changing
the name of the model in this fairly mature application is going to be
some work. But at least it all makes some sense now.

Is it possible to change the model name without changing the name of the
associations that point to it in other models? Or, I guess, to alias
the association name ‘request’ to an ‘actual’ association named
service_request or whatever. To give me less code that has to be
changed? Any advice as to the lowest impact way to change a model name
in a mature application with lots of code that refers to that model, and
to associations in other models that point to that model?

Odd that I got away with it in Rails 1.x, but oh well, I guess it was
really incorrect all along.

Jonathan

Chris B. wrote:

Jonathan is probably right. ‘Request’ is a reserved word in Rails -
see http://wiki.rubyonrails.org/rails/pages/ReservedWords

Try changing the model name to ServiceRequest or similar.

On Nov 7, 6:43�am, Jonathan R. <rails-mailing-l…@andreas-


#8

On 10 Nov 2008, at 21:04, Jonathan R. wrote:

Hmm, just changing the model name from Request to AppRequest doesn’t
seem to have done it.

I tried to leave the (many) associations pointing to AppRequest (nee
Request) the same, but specify a :class_name and :foreign_key.

It sounds like maybe “request” as the name of an assocation, even when
not the name of the model, is a no-no too?

I’m not convinced that has anything to do with this at all. If you
could post your teeny tiny example I might be able to work out what is
going in (given that I wrote the code behind include in 2.1.2)

Fred


#9

Yeah, you’re right, sorry, thanks so much for your help. Probably for
the best that i changed the model name from Request anyway, might as
well commit that to my svn since it’s advertised as a Rails reserved
word.

I just posted this to the forum with a different subject, since it ended
up having nothing to do with this, but. But I was forced to really get
down and dirty with my testing, and it turns out it’s because I had
over-ridden [] and []= on one of the models involved. I got away with
that in Rails 1 (perhaps AR didn’t used to use these methods?), but not
in Rails 2. Okay, more refactoring, this one’s even more of a pain then
the last one. Oh well, I guess I was being too clever before.

Jonathan

Frederick C. wrote:

On 10 Nov 2008, at 21:04, Jonathan R. wrote:

Hmm, just changing the model name from Request to AppRequest doesn’t
seem to have done it.

I tried to leave the (many) associations pointing to AppRequest (nee
Request) the same, but specify a :class_name and :foreign_key.

It sounds like maybe “request” as the name of an assocation, even when
not the name of the model, is a no-no too?

I’m not convinced that has anything to do with this at all. If you
could post your teeny tiny example I might be able to work out what is
going in (given that I wrote the code behind include in 2.1.2)

Fred


#10

On 10 Nov 2008, at 22:32, Jonathan R. wrote:

over-ridden [] and []= on one of the models involved. I got away with
that in Rails 1 (perhaps AR didn’t used to use these methods?), but
not
in Rails 2. Okay, more refactoring, this one’s even more of a pain
then
the last one. Oh well, I guess I was being too clever before.

Rails has always provided [] and []= for getting/setting
attributes. :include was largely rewritten in 2.1 and does indeed use
[] to read attributess, the corresponding bits of 2.0 or 1.2 obviously
didn’t

Fred


#11

The odd thing is that I get away with over-riding [] and []= until I try
defining an association with a pre-fetch :include that involves the
model with the over-ridden [] and []=. And googling around, I can see
several people suggesting over-ridding [] and []= on an AR model to
accomplish various clever things. So maybe it is a bug? Regardless, I
think I’ll try to refactor to do not do that to avoid the risk of
getting in the way of AR. It seems to be rather easier than one would
like to get in the way of AR.

In particular, the too-clever thing I was doing was having an AR that
could take arbitrary keys and either store them in an attribute, if it
exists, or in a serialized hash, if otherwise. An excerpt of the
relevant stuff:

def MyThing < ActiveRecord::Base
serializes :my_data

def
if ( has_attribute?(key) )
self.send(key)
else
my_data[key]
end
end

def []=(key, value)
if ( has_attribute?(key) )
self.send(key.to_s+’=’, value)
else
my_data[key] = value
end
end

All well and good–until I try to define an association with :include =>
MyThing .

Jonathan R. wrote:

Yeah, you’re right, sorry, thanks so much for your help. Probably for
the best that i changed the model name from Request anyway, might as
well commit that to my svn since it’s advertised as a Rails reserved
word.

I just posted this to the forum with a different subject, since it ended
up having nothing to do with this, but. But I was forced to really get
down and dirty with my testing, and it turns out it’s because I had
over-ridden [] and []= on one of the models involved. I got away with
that in Rails 1 (perhaps AR didn’t used to use these methods?), but not
in Rails 2. Okay, more refactoring, this one’s even more of a pain then
the last one. Oh well, I guess I was being too clever before.

Jonathan

Frederick C. wrote:

On 10 Nov 2008, at 21:04, Jonathan R. wrote:

Hmm, just changing the model name from Request to AppRequest doesn’t
seem to have done it.

I tried to leave the (many) associations pointing to AppRequest (nee
Request) the same, but specify a :class_name and :foreign_key.

It sounds like maybe “request” as the name of an assocation, even when
not the name of the model, is a no-no too?

I’m not convinced that has anything to do with this at all. If you
could post your teeny tiny example I might be able to work out what is
going in (given that I wrote the code behind include in 2.1.2)

Fred