Incorrectly using parent class table_name when specifying self.table_name explicitly.

[jensb1]

class A < ActiveRecord::Base
end
clas B < A
self.table_name = 'b'
end

B.first will try to "select * from a" instead of 'select * from b'

[jensb1]

See https://github.com/jensb1/test_4578

test.rb

require './config/environment.rb'
B1.first
B1.new #FAILS

Backtrace:

jens@jenspro:~/Documents/Projects/apoex/test_4578$ ruby test.rb 
/Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/connection_adapters/sqlite_adapter.rb:470:in `table_structure': Could not find table 'a1s' (ActiveRecord::StatementInvalid)
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/connection_adapters/sqlite_adapter.rb:351:in `columns'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/connection_adapters/schema_cache.rb:12:in `block in initialize'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/model_schema.rb:228:in `yield'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/model_schema.rb:228:in `default'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/model_schema.rb:228:in `columns'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/model_schema.rb:248:in `column_names'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/attribute_methods.rb:47:in `block in define_attribute_methods'
    from <internal:prelude>:10:in `synchronize'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/attribute_methods.rb:44:in `define_attribute_methods'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/attribute_methods.rb:46:in `block in define_attribute_methods'
    from <internal:prelude>:10:in `synchronize'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/attribute_methods.rb:44:in `define_attribute_methods'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/attribute_methods.rb:148:in `respond_to?'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activesupport-3.2.0/lib/active_support/callbacks.rb:398:in `__run_callback'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activesupport-3.2.0/lib/active_support/callbacks.rb:385:in `_run_initialize_callbacks'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activesupport-3.2.0/lib/active_support/callbacks.rb:81:in `run_callbacks'
    from /Users/jens/.rvm/gems/ruby-1.9.3-p0@ruby-1.9.3-apoex2/gems/activerecord-3.2.0/lib/active_record/base.rb:491:in `initialize'
    from test.rb:3:in `new'
    from test.rb:3:in `<main>'

[jensb1]

didn't write so, but this works in 3.1.3

[tenderlove]

Out of curiosity, why would you do this? If there is no A table, you should set the class to be abstract. If there is an A and a B table, you should make the B model inherit from AR::Base.

[airblade]

I think this is causing me a problem in my paper_trail gem (used for versioning model data), specifically paper-trail-gem/paper_trail#125 and paper-trail-gem/paper_trail#128.

Most of the time paper_trail stores versions in a table called versions, but we allow people to use custom version classes, and hence tables, so they can store different models' versions in separate tables.

People set this up as described in the Custom Version Classes section in the README (sorry no link directly to the line number).

PaperTrail then sets it up like this.

However the custom table name of a subclass of paper_trail's version class is ignored in Rails 3.2, which means Rails cannot find the table.

Is this easy to fix? I'd be happy to have a go if you can point me in the right direction.

[airblade]

I think the problem is ActiveRecord assumes a subclass of an AR model will be using STI. This is not true in my case.

Hmm, having said that, the compute_table_name method used the same logic in v3.1.0.

[isaacsanders]

Is this still an issue? Any thoughts on this @tenderlove / @josevalim?

[jensb1]

Not for me anyway, "workaround" exists.

4 maj 2012 kl. 21:56 skrev Isaac Sanders
reply@reply.github.com:

Is this still an issue? Any thoughts on this @tenderlove / @josevalim?

---

Reply to this email directly or view it on GitHub:
#4578 (comment)

[isaacsanders]

@jensb1 Would you mind closing this then?

[jbirdjavi]

This is still an issue for me and is keeping me from upgrading a couple apps to 3.2. I can't use the abstract class workaround for these apps since I'm inheriting from a class that's inside a gem and need to change the table name along with some other methods from the parent class.