I agree. I've been doing Rails for 10 years (and databases for going on 25)), and "belongs_to" has always been a cognitive blocker for me.
I wouldn't do away with "belongs_to", but making "has_key_for" aliases sounds like a great idea, for people who want to write their code that way. But, most likely this should be in a gem, probably not a lot of chance of it making it into official Rails (I may be wrong, but I doubt it). -- Chad On Sat, Sep 24, 2016 at 2:01 AM, Richard McSharry <[email protected]> wrote: > Any framework that has convention over configuration has the the problem > that newcomers have to learn the conventions. > > I think that one of the biggest stumbling blocks to new users of Rails is > the way associations are described. Just look at the number of questions on > this on SO. M-1 and 1-M and even M-1-M are really quite simple concepts, > but the Rails naming of these relationships just serves to confuse. > > Here is a good definition that kind of gets at the root cause: > > > belongs_to and has_many do not describe either the ownership or the > scope or the life cycles for the objects they relate. They may give that > impression because 'belongs' implies ownership and responsibility, but they > merely describe the references (the keys) between the objects. > > Even the [documentation](http://api.rubyonrails.org/classes/ > ActiveRecord/Associations/ClassMethods.html) states: > > > Associations are a set of macro-like class methods for tying objects > together through foreign keys > > In that case isn't it easier if we called a spade a spade, and not a > shovel? ;) > > Surely all the confusion would be cleared up by renaming `belongs_to`? > This would lower the barrier to learning Rails, resulting in less mistakes, > less time wasted asking and answering on SO, less discussions, less blogs > -> overall a HUGE time saver for the community **over the long term** > (against which you have to weigh the short-term pain of adopting the change > of course). > > **Example 1 - one-to-one** > ```ruby > class Employee > has_one :salary > end > class Salary > has_key_for :employee > end > ``` > > **Example 2 - one-to-many** > ```ruby > class Manager > has_many :employees > end > class Employee < ActiveRecord::Base > has_key_for :manager > end > ``` > > **Example 3- M-1-M** > ```ruby > class Project > has_many :assignments > has_many :employees, through: :assignments > end > > class Employee > has_many :assignments > has_many :projects, through: :assignments > end > > class Assignment > has_key_for :employee > has_key_for :project > end > ``` > > **Example 4 - Polymorphic** > ```ruby > class Address > has_key_for :addressable, :polymorphic => true > end > > class Person > has_one :address, as: :addressable > end > ``` > > I think this just leaves "has_and_belongs_to_many" which personally I have > always hated. :) Why not just use "has_many"? Since when you have an > explicit join table for M-M, you use "through"...so if there is no > "through" specified, we know it is a HABTM. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
