Question

I’m using Rails 2.3.14

UPDATE 3 the trick I found in update 2 only works for the first access of the association… so, I stick the set_table_name lines in my application controller. This is so weird. I hope this gets fixed. =\

UPDATE 2 if I manually / nastily / hackily set teh tables for the troublesome classes at the bottom of my environment file, I stop getting the errors.

app/config/environment.rb:

Page::Template::Content.set_table_name "template_page_contents"
Page::Template::Section.set_table_name "template_page_sections"

Why do I have to do this? is rails broken for this particular use case?

UPDATE: it appears that set_table_name isn’t working when it’s initially called in my Page::Template::Content class.

but if I call it right before I use the association, it works…

ap Page::Template::Content.table_name # prints "contents"
Page::Template::Content.set_table_name "template_page_contents"
ap Page::Template::Content.table_name # prints "template_page_contents"

return self.page_template_contents.first # doesn't error after the above is exec'd

ORIGINAL QUESTION:

TL; DR: I have a has_many relationship that I’m trying to access, but Rails thinks that the table that the has_many relationship uses is a different table

I’ve been getting this error, where when I try to access a Page::Template::Content that belongs_to a Page::Template via a has_many relationship.

Mysql2::Error: Unknown column 'contents.template_page_id' in 'where clause': SELECT * FROM `contents` WHERE (`contents`.template_page_id = 17)  LIMIT 1

Looking at the error logs, I figured I needed to starting using some print statements to find out why rails was trying to find the associated objects in the wrong table.

gems_path/activerecord-2.3.14/lib/active_record/associations/association_collection.rb:63:in `find'

I just decided to print the @reflection object since everything seems to be happening around that. Here is how I did that:

  require "awesome_print" # best console printer (colors, pretty print, etc)
  def find(*args) # preexisting method header
     ap "-------" # separator so I know when one reflection begins / ends, etc
     ap @reflection # object in question
     ... # rest of the method

Last ‘@reflection’ that printed before the error:

"-------"
#<ActiveRecord::Reflection::AssociationReflection:0x108d028a8
    @collection = true,
    attr_reader :active_record = class Page::Template < LibraryItem {...},
    attr_reader :class_name = "Page::Template::Content",
    attr_reader :klass = class Content < LibraryItem {...},
    attr_reader :macro = :has_many,
    attr_reader :name = :page_template_contents,
    attr_reader :options = {
        :foreign_key => "template_page_id",
         :class_name => "Page::Template::Content",
             :extend => []
    },
    attr_reader :primary_key_name = "template_page_id",
    attr_reader :quoted_table_name = "`contents`"
>

there are a couple things wrong in the above block of code.

:klass should be Page::Template::Content
:name should be :contents  
:quoted_table_name should be `contents`

How my models are set up:

app/models/page.rb:

class Page < LibrayItem
  belongs_to :template_page, :class_name => "Page::Template"

app/models/page/template.rb

class Page::Template < Library Item
  set_table_name "template_pages"
  has_many :page_template_contents,
    :class_name => "Page::Template::Content",
    :foreign_key => "template_page_id"

app/models/page/template/content.rb

class Page::Template::Content
  set_table_name "template_page_contents"
  belongs_to :template_page,
    :class_name => "Page::Template",
    :foreign_key => "template_page_id"



class Page::Template
...
    return self.page_template_contents.first

the class the association is choosing (unrelated to my page / template structure above):

class Content < LibraryItem
  set_table_name "contents"
# no associations to above classes

So… what is causing this and how do I fix it?

Answer 1

Your issue is not due to set_table_name but rather due to how Rails finds the target model class in an association and the fact that you have a top-level model (Content) which shares its name with a model nested in a deeper namespace (Page::Template::Content). The weird difference in behaviour is most likely due to differences in what classes are actually loaded at the time the association is examined (remember that by default in development mode Rails loads model classes on demand when they are first referenced).

When you define an association (whether you specify the class name of the target model of the association explicitly as you have done or accept the default), Rails has to turn the name of the target model class into a Ruby constant so that it can refer to that target class. To do this, it invokes the protected class method compute_type on the model class that is defining the association.

For example, you have

class Page::Template < LibraryItem
  set_table_name "template_pages"
  has_many :page_template_contents,
    :class_name => "Page::Template::Content",
    :foreign_key => "template_page_id"
 end

You can test in the Rails console how compute_type works for this class:

$ ./script/console 
Loading development environment (Rails 2.3.14)
> Page::Template.send(:compute_type, "Page::Template::Content")
=> Page::Template::Content(id: integer, template_page_id: integer)

I see the result is, as I expect, a reference to the class Page::Template::Content.

However, if I restart the Rails console but this time cause the model class Content to be loaded first (by referencing it) and then try again, I see this (I didn’t bother creating a table for the Content model, but that doesn’t change the significant behavior):

$ ./script/console 
Loading development environment (Rails 2.3.14)
>> Content # Reference Content class so that it gets loaded
=> Content(Table doesn't exist)
>> Page::Template.send(:compute_type, "Page::Template::Content")
=> Content(Table doesn't exist)

As you can see, this time I get a reference to Content instead.

So what can you do about this?

Well, first of all, you should realize that using namespaced model classes in Rails (certainly in 2.3) is a real pain. It’s nice to organize your model classes in a hierarchy but it certainly does make life more difficult. As you can see above, if you have a class in one namespace that has the same name as a class in another namespace, this gets more hairy.

If you still want to live with this situation, I can make a couple of suggestions. One of the following may help:

1. Turn on class caching in development mode. This will cause all model classes to be preloaded rather than loading them on demand as is the default. It will make your code above more predictable, but may make development somewhat unpleasant (since classes will no longer be reloaded with each request).

2. Explicity require dependent classes in classes with problematic associations. For example:

   class Page::Template < LibraryItem        
     require 'page/template/content'
     set_table_name "template_pages"
     has_many :page_template_contents, ...
   end
   

3. Override the compute_type method in your classes where you know referencing associated class may go awry so that it returns the namespaced class no matter what. Without knowing your class hierachy in more detail I cannot give a full suggestion on how to do this, but a quick and dirty example follows:

   class Page::Template < LibraryItem
     set_table_name "template_pages"
     has_many :page_template_contents,
       :class_name => "Page::Template::Content",
       :foreign_key => "template_page_id"
   
     def self.compute_type(type_name)
       return Page::Template::Content if type_name == "Page::Template::Content"
       super
     end
   end