Active Record Inheritence

Greetings,

I’m having some troubles getting single table inheritance
working. I’m outside of rails, and I think I understand
the way this whole thing is supposed to work. I’ve got
tables in a PostgreSQL database, (principal and user, the
User class extends Principal).

When I run the following code I get an error like so:

/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1789:in
method_missing': undefined methodfirst_name=’ for
#<User:0xb7d815cc @attributes={“type”=>“User”},
@new_record=true> (NoMethodError)

When I change the class definition of User to extend
ActiveRecord::Base the code works and I wind up with rows in
the users table.

Any ideas what I’m not doing correctly?

The code:

#!/usr/bin/ruby

#CREATE TABLE principals (

id integer DEFAULT nextval(‘id_seq’::text) NOT NULL,

“type” text

#);

#CREATE TABLE users (

id integer DEFAULT nextval(‘id_seq’::text) NOT NULL,

username text,

“password” text,

first_name text,

last_name text

#);

require ‘rubygems’
require ‘active_record’

ActiveRecord::Base.establish_connection(
:adapter => “postgresql”,
:host => “localhost”,
:username => “org”,
:password => “xx”,
:database => “org”
)

class Principal < ActiveRecord::Base

end

class User < Principal

end

u = User.new
u.first_name = ‘joejoe’

Hi –

On Sun, 15 Oct 2006, Andrew L. wrote:

/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1789:in

id integer DEFAULT nextval(‘id_seq’::text) NOT NULL,

:adapter => “postgresql”,
class User < Principal

end

u = User.new
u.first_name = ‘joejoe’

If you want to do single table inheritance, you need to use a single
table :slight_smile: You’re using two (principals and users).

Try the following:

  1. add a type/text column to users
  2. get rid of principals
  3. in the models, do:
class User < ActiveRecord::Base
end

class Principal < User
end

I know I’ve reversed the inheritance flow; it seems to make more sense
this way, but you can of course switch it around.

David

[email protected] wrote:

  1. in the models, do:

David

Thanks for your comments. It seems I completely missed
what single table inheritance is all about. You’d thing by
calling it single table, I’d have gotten that it was
single_table… I’m hoping to have other principal types
in my system (groups, systems, users, etc). I guess I’ll
need to work something out with
has_a, am I pointing in the right direction?

Thanks.

Andy

Hi –

On Sun, 15 Oct 2006, Andrew L. wrote:

Try the following:

table, I’d have gotten that it was single_table… I’m hoping to have other
principal types in my system (groups, systems, users, etc). I guess I’ll
need to work something out with
has_a, am I pointing in the right direction?

The has_one stuff is separate from the STI stuff. The basic idea of
STI is that you have one table (principals [switching my example back
to the way yours was]) that has columns for all of the attributes
that any of the descendants might have. In other words, the single
table is a flattened, centralized collection. This is, in a sense,
illogical. It means that if you have, say, a people table, and then
subclasses of Person like Employee and Customer, technically Customers
will have all of the same characteristics as Employees – including,
perhaps, salary. The point though is that in exchange for a bit of
weirdness in the database table, you receive a lot of ease at the Ruby
end, where you can accomplish a lot just through inheritance.

In the case you’re describing, if principals is the single table, it
would have to include all the future fields for groups, systems, and
users. That makes me wonder whether STI is actually a good fit for
this case. You should only use STI when the descendant classes are
pretty similar, and only diverge in a small number of fields. It
sounds like a system and a user would be very different from each
other.

The associations (has_one/belongs_to, etc.) might make more sense
here. A User could belong_to a group; Group would have many users;
and so forth.

David

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs