Forum: Ruby on Rails Naming Conventions for Associations

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
9a552735a02d1ae44cb37e8d8ea9037c?d=identicon&s=25 David T. (Guest)
on 2009-03-26 14:38
(Received via mailing list)
Hi Everyone,

I seem to continually have this internal debate on how I should
approach naming certain associations on models.  For example, let's
say I have a User model and a User has one Status.  Although, let's
also say that in my system that 'Status' would be ambiguous with other
types of statuses, so I want to name the model UserStatus.  The
problem that I face now, is that when I say a user has one UserStatus,
the way I would refer to the associated model would, by default, look
like:

@user.user_status

I feel that in this context, the double 'user' references are
redundant.  Something like this would be more natural:

@user.status (where status is UserStatus)

I realize that I can achieve the second syntax in a couple of ways.
In the User model, I can change the association name, like:

belongs_to :status, :class_name => 'UserStatus', :foreign_key =>
'user_status_id'

This works, but it creates the getters/setters:

@user.status
@user.user_status_id

I would expect for it to also let me change the id through something
like @user.status_id, not @user.user_status_id.   So, this only cleans
things up half-way.

I realize too, that I can rename the actual database foreign key to
status_id instead of user_status_id, and then do something like this
in my user model:

belongs_to :status, :class_name => 'UserStatus'

This let's me access the status and status_id setters/getters as I
would expect.  The thing about both of these changes though is that I
feel like I'm straying from the conventions, which I really want to
try to avoid.  I wanted to get a survey of how other people usually
approach this.  Any advice with this would be appreciated.

Thanks,
David
Aad37b5f7116c8d1f547d23b37566032?d=identicon&s=25 Greg Donald (destiney)
on 2009-03-26 20:18
(Received via mailing list)
On Thu, Mar 26, 2009 at 8:29 AM, David T. <jellyrolldt@gmail.com> wrote:
> I seem to continually have this internal debate on how I should
> approach naming certain associations on models.  For example, let's
> say I have a User model and a User has one Status.  Although, let's
> also say that in my system that 'Status' would be ambiguous with other
> types of statuses, so I want to name the model UserStatus.  The
> problem that I face now, is that when I say a user has one UserStatus,
> the way I would refer to the associated model would, by default, look
> like:


Sounds like you want a polymorphic association.

http://wiki.rubyonrails.org/howtos/db-relationship...




--
Greg Donald
http://destiney.com/
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2009-03-26 20:35
Greg Donald wrote:
> On Thu, Mar 26, 2009 at 8:29 AM, David T. <jellyrolldt@gmail.com> wrote:
>> I seem to continually have this internal debate on how I should
>> approach naming certain associations on models. �For example, let's
>> say I have a User model and a User has one Status. �Although, let's
>> also say that in my system that 'Status' would be ambiguous with other
>> types of statuses, so I want to name the model UserStatus. �The
>> problem that I face now, is that when I say a user has one UserStatus,
>> the way I would refer to the associated model would, by default, look
>> like:
>
>
> Sounds like you want a polymorphic association.

If it were me, I would also consider whether a status warrants a
separate model in the first place. I would consider managing a user's
status using a "finite state machine" design pattern.

Of course, it's entirely possible that your design does warrant a
separate UserStatus model, but the generic nature of Status leads me to
think maybe it doesn't. I'm just saying that sometimes de-normalizing a
database schema can greatly simplify the system design. And in some
cases even increase system's performance.
9a552735a02d1ae44cb37e8d8ea9037c?d=identicon&s=25 David T. (Guest)
on 2009-03-26 21:18
(Received via mailing list)
Thank you both for your suggestions.  For one reason or another, these
options didn't occur to me originally in this situation, even though I
was familiar with both.  Both make a lot of sense -- you've given me a
lot to think about for now.  Thanks!
This topic is locked and can not be replied to.