Hi --

On Sun, 15 Oct 2006, Andrew Libby wrote:

>
>
>
> dblack / wobblini.net wrote:
>> Hi --
>> 
>> 
>> If you want to do single table inheritance, you need to use a single
>> table :-)  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
>> 
>
>
> 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?

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

-- 
                   David A. Black | dblack / wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org