Rails 2.1.2, complex find involving complex include, bug?

So I’m upgrading my app from Rails 1.2.6 to Rails 2.1.2.

I have a complex find statement that worked in 1.2.6 and isn’t working
in 2.1.2. I think maybe this is a bug, although maybe there’s something
else I could be doing to work-around it?

My find statement involves:

  • Models in a module for namespace purposes
  • a join clause with raw SQL
  • an includes clause with multiple levels (the hash syntax)

This worked in 1.2.6:


joins = " inner join AZ_LETTER_GROUP_VER3 as lg on

AZ_TITLE_VER3.AZ_TITLE_VER3_ID = lg.AZ_TITLE_VER3_ID"

conditions = ['lg.AZ_LETTER_GROUP_VER3_NAME = ?', 'A']
batch_size = 10
page = 1


az_titles = SfxDb::AzTitle.find(:all,
    :joins => joins,
    :conditions => conditions,
    :limit => batch_size,
    :offset=>batch_size*(page -1),
    :order=>'TITLE_SORT',
    :include=>[{:sfx_object => [:publishers, :titles] }])

However, in 2.1.2, it raises an error, ActiveRecord can’t find the
SfxObject model class anymore–probably because it’s in a module
namespace, SfxDb::SfxObject. It says:

uninitialized constant SfxObject
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.2/lib/active_support/dependencies.rb:279:in
load_missing_constant' [...] /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.2/lib/active_support/core_ext/string/inflections.rb:143:inconstantize’
[…]
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations.rb:1652:in
remove_duplicate_results!' [...] /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations.rb:1261:infind_with_associations’

Now, here’s the weird thing. If I remove that complex include
statement, and remove the extra levels, it works fine:

az_titles = SfxDb::AzTitle.find(:all,
    :joins => joins,
    :conditions => conditions,
    :limit => batch_size,
    :offset=>batch_size*(page -1),
    :order=>'TITLE_SORT',
    :include=>[:sfx_object])

So this smells like a bug to me. I need those extra levels for
efficiency!

Also, if I remove the models from a module namespace, it works fine.

So it seems to be a bug in the code for multi-level include and models
in modules.

Should I report this bug somewhere/somehow? Not sure of Rails bug
reporting standards.

I guess the workaround is to remove my models from a module namespace.
But that’s really unfortunate, it keeps things so much tidier to have
them there, they’re really a special purpose subset of my models. Can
anyone think of any other workaround?

Hmm, again answering my own question as soon as I ask it (writing this
stuff out is sure helpful for clarifying your thoughts), poking around
in the AR documentation leads me to another workaround. Specify the
classname explicitly in the model relationships, even though it really
shouldn’t be needed.

module SfxDb
class AzTitle < SfxDbBase

  belongs_to :sfx_object,
           :class_name => "SfxDb::SfxObject"

[…]

end

That’s a reasonable workaround, although it really shouldn’t be
neccesary. Anyone want to help me figure out the right way to report
this as a bug?

Jonathan

Jonathan R. wrote:

So I’m upgrading my app from Rails 1.2.6 to Rails 2.1.2.

I have a complex find statement that worked in 1.2.6 and isn’t working
in 2.1.2. I think maybe this is a bug, although maybe there’s something
else I could be doing to work-around it?

My find statement involves:

  • Models in a module for namespace purposes
  • a join clause with raw SQL
  • an includes clause with multiple levels (the hash syntax)

This worked in 1.2.6:


joins = " inner join AZ_LETTER_GROUP_VER3 as lg on

AZ_TITLE_VER3.AZ_TITLE_VER3_ID = lg.AZ_TITLE_VER3_ID"

conditions = ['lg.AZ_LETTER_GROUP_VER3_NAME = ?', 'A']
batch_size = 10
page = 1


az_titles = SfxDb::AzTitle.find(:all,
    :joins => joins,
    :conditions => conditions,
    :limit => batch_size,
    :offset=>batch_size*(page -1),
    :order=>'TITLE_SORT',
    :include=>[{:sfx_object => [:publishers, :titles] }])

However, in 2.1.2, it raises an error, ActiveRecord can’t find the
SfxObject model class anymore–probably because it’s in a module
namespace, SfxDb::SfxObject. It says:

uninitialized constant SfxObject
/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.2/lib/active_support/dependencies.rb:279:in
load_missing_constant' [...] /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.2/lib/active_support/core_ext/string/inflections.rb:143:inconstantize’
[…]
/usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations.rb:1652:in
remove_duplicate_results!' [...] /usr/lib/ruby/gems/1.8/gems/activerecord-2.1.2/lib/active_record/associations.rb:1261:infind_with_associations’

Now, here’s the weird thing. If I remove that complex include
statement, and remove the extra levels, it works fine:

az_titles = SfxDb::AzTitle.find(:all,
    :joins => joins,
    :conditions => conditions,
    :limit => batch_size,
    :offset=>batch_size*(page -1),
    :order=>'TITLE_SORT',
    :include=>[:sfx_object])

So this smells like a bug to me. I need those extra levels for
efficiency!

Also, if I remove the models from a module namespace, it works fine.

So it seems to be a bug in the code for multi-level include and models
in modules.

Should I report this bug somewhere/somehow? Not sure of Rails bug
reporting standards.

I guess the workaround is to remove my models from a module namespace.
But that’s really unfortunate, it keeps things so much tidier to have
them there, they’re really a special purpose subset of my models. Can
anyone think of any other workaround?

We have encountered similar issues. We finally decided not rely on Rails
finding any classes declared in a module namespace. We liked the
organization that the module namespace provided as our models directory
was getting pretty large. So we kept our file structure as is, but
removed the namespace. Instead, we explicity “require” the classes in
our environment.rb file. For example:

require File.dirname(FILE) + ‘/…/app/models/reports/stats_report’
require File.dirname(FILE) +
‘/…/app/models/reports/standings_report’

This is a nasty bug and I hope it gets fixed soon. It’s unfortunate
Rails does not deal with namespaces properly – at least I think it’s a
Rails issue.

John

Have you reported it?

On Nov 12, 9:30 pm, John H. [email protected]