How to ignore :type in some cases? (when I don't want STI)

Rails
1

Hi,

I have a model Member containing details such as name, address, phone,
etc.
There are various approval stages for new and changed members so I need
a few
extra models based on member, some can use STI, some I’d prefer not to
use
STI.

MemberMod which stores a modified member in the members table using STI.
This
is necessary because there are approval stages to a modification. This
is
working fine and the simplified model looks like this:

class MemberMod < Member
belongs_to :original_member, :class_name => ‘Member’,
:foreign_key => :original_member_id
end

I have a few other models that are very similar to MemberMod (such as
MemberTransfer) which should have no problem using the STI method,
however …

I’m now creating a MemberProposal model which needs all the fields of a
Member
and a bunch more. I was planning to use a member_proposals table for
the
extra details but to store the routine member details in the members
table
(to avoid duplicating it all) - however I need the record in members
table to
be easily recognizable as a “proposed member” not a “member” - I have
issues,
here’s the simplified model:

class MemberProposal < ActiveRecord::Base
# most details we store in a member record with type set to
MemberProposal
belongs_to :member
end

The issue is that when I try to access models that belong_to member it
fails,
things like:

member_proposal.member.club
member_proposal.member.state
member_proposal.member.country

It fails because it thinks Member is a MemberProposal and not a Member
(technically I suppose it’s correct). Is there any way to turn off the
magic
interpretation of member[:type] for this use case or do I need to change
my
scheme entirely?

Thanks

Fraser C. [email protected]
Georgetown, Ontario, Canada

2

I have a model Member containing details such as name, address, phone, etc.
There are various approval stages for new and changed members so I need a few
extra models based on member, some can use STI, some I’d prefer not to use
STI.

It fails because it thinks Member is a MemberProposal and not a Member
(technically I suppose it’s correct). Is there any way to turn off the magic
interpretation of member[:type] for this use case or do I need to change my
scheme entirely?

I’d consider re-architecting your design. Creating new member-like
models for members with different approval stages seems clunky to me.
How about simply having Member and ApprovalStage models, so that you
can find members by approval stage?

3

On Tuesday 15 May 2007 08:56:27 Mark T. wrote:

I’d consider re-architecting your design. Creating new member-like
models for members with different approval stages seems clunky to me.
How about simply having Member and ApprovalStage models, so that you
can find members by approval stage?

First thanks for reply. Yes, I realized I was going down a very dark
road the
more I thought about this. STI provides just a little too much magic (I
had
already hacked around it for a few cases). I think abstract classes are
the
way to go:

  • MemberDetails = abstract class (no table) base for all other types of
    member
  • Member = regular member
  • MemberProposal = mostly like a member but with some extra detail
  • MemberMod = all fields of a member plus pointer to the original member
  • MemberTransfer = similar to MemberMod

By using an abstract base class all my validations can be in the single
model
and I can continue to use all of the code I’ve developed without change
(a
nice bonus).

I had wanted to avoid having multiple very similar tables but the more I
think
about it I don’t see a problem with it.

–
Fraser C. [email protected]
Georgetown, Ontario, Canada