An example from this blog
class Tag < ActiveRecord::Base
attr_accessible :name, :taggable_id, :taggable_type
belongs_to :taggable, :polymorphic => true
end
class Car < ActiveRecord::Base
attr_accessible :name
has_many :tags, :as => :taggable
end
class Bike < ActiveRecord::Base
attr_accessible :name
has_many :tags, :as => :taggable
end
It looks to me we could do thing like this without polymorphic associations
class Tag < ActiveRecord::Base
attr_accessible :name,
belongs_to :cars,
belongs_to :bikes,
end
class Car < ActiveRecord::Base
attr_accessible :name
has_many :tags
end
class Bike < ActiveRecord::Base
attr_accessible :name
has_many :tags
end
What is the difference of with polymorphic associations and without?
THanks
In your last example, Car has many tags, so conventionally the "tags" table will have a field car_id. Now Bike has many tags, so one more field bike_id.
Without Polymorphic, how many fields are you going to create for the tags table? :)
Even you guarantee that there will only be two models have tag ultimately, there will also lots of null data in the table, say a bike doesn't have car_id, and that is not nice.
Polymorphism solved this problem by defining a common interface so that Car and Bike can share same operations with different sub type. http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Polymorphism_in_object-oriented_programming.html
A polymorphic association allows you to create a table with relationships between multiple models.
Consider your example. Both Car and Bike can have many tags, so instead of creating two different tables, say car_tags and bike_tags, you can use a single polymorphic table named Tag which not only stores the foreign key (in a column named resource_id), but also the type of resource it's associated with (in a column named resource_type), which, in this case would be Car or Bike.
In summary, polymorphic relationships are between many different models whereas normal relationships are, generally speaking, only between two.
You can find more information in the RoR Guides; http://guides.rubyonrails.org/association_basics.html#polymorphic-associations
Hope that helps clarify things a bit.
Polymorphic associations allow for a single model to belong to multiple models on a single association[1]. Taking your example above, simply adding has_many :tags to the Car and Bike models and belongs_to :car and belongs_to :bike to the Tag model has two major shortcomings:
It introduces a glut of foreign keys of which a large quantity will have no value
It still doesn't allow for a tag to belong to more than one model
Some great resources for learning more about polymorphic associations are listed below.
RailsGuides on Polymorphic
Associations
RailsCasts #154 Polymorphic Associations
(revised)
What's the Deal with Rails' Polymorphic
Associations?
Related
I'm transitioning from "Laravel ORM" to "Rails Active Record" and I couldn't find how do you do something like this:
$this->people()->attach($person['id'], ['role' => $role]);
Explanation for Laravel code snippet
People is a polymorphic association to the class that is being accessed via $this via the Role class. The function above, creates a record in the middle table (roles/peopleables) like this:
id: {{generically defined}}
people_id: $person['id']
role: $role
peopleable_type: $this->type
peopleable_id: $this->id
How the association is defined on the Laravel end:
class XYZ {
...
public function people()
{
return $this->morphToMany(People::class, 'peopleable')->withPivot('role','id');
}
...
}
My efforts in Ruby
Here is how I made the association in Ruby:
class Peopleable < ApplicationRecord
belongs_to :people
belongs_to :peopleable, polymorphic: true
end
class People < ApplicationRecord
has_many :peopleables
end
class ApplicationRecord < ActiveRecord::Base
self.abstract_class = true
end
I have seen the operation << but I don't know if there is any way to set an additional value on the pivot table while triggering this operation. [in this case the roles or peopleables tables; I use these two terms interchangeably in this app.]
PS. So, basically the question is how to define additional values on the pivot table in a polymorphic-many association in ActiveRecord and dynamically set those values while initiating an attachment relationship
Description of Functionality
Our application has a limitless [generally speaking, not that there is no computational limits!] content type: post, novel, poem, etc.
Each of these content types can be associated to individuals who play certain roles: editor, author, translator, etc.
So, for example:
X is the translator of Post#1. X, Y and Z are authors of Post#1.
There is a distinct People model and each content type has its own unique model [for example: Post, Poem, etc].
The idea of :through is referring to the 'Role class' or 'the pivot table' [whichever way you want to understand it] that the polymorphic association is recorded on it.
In addition to the information regarding a simple polymorphic relationship, there is also the kind of role that is recorded on the pivot table.
For example, X is both the author and the translator for Post#1, so there are two rows with the same people_id, peopleable_type and peopleable_id, however they have different values for role.
From what I understand given your description, I think you have this models (I'll change the names to what I understand they are, hope it's clear enough):
class Person < ApplicationRecord # using singular for models
has_many :person_roles
end
class Poem < ApplicationRecord
has_many :person_roles, as: :content
end
class Novel < ApplicationRecord
has_many :person_roles, as: :content
end
etc...
class PersonRole < ApplicationRecord
belongs_to :person
belongs_to :content, polymorphic: true
# you should have a "role" column on your table
end
So a Person is associated to a "content" (Novel, Poem, etc) via the join model PersonRole with a specific role. A Person that is the author of some novel and the editor of some peom would have two PersonRole records.
So, if you have a person and you want to assign a new role on some content, you can just do:
person.person_roles.create(role: :author, content: some_poem)
or
PersonRole.create(person: person, role: :author, content: some_poem)
or
some_poem.person_roles.create(person: person, role: :author)
You have two things in play here: "belongs_to :content, polymorphic: true" is covers the part of this being a polymorphic association. Then you have the "PersonRole" table that covers the part you know as "pivot table" (join table/model on rails).
Note that :through in rails has other meaning, you may want to get all the poems that a user is an author of, you could then have a "has_many :poems, through: :person_roles" association (that won't actually work, it's more complex than that in this case because you have a polymorphic association, you'll need to configure the association with some extra options like source and scope for this to work, I'm just using it as an example of what we understand as a has many :through association).
Rails is 'convention over configuration'. Models' must be in singular 'Person'.
ActiveRecord has has_many ... through and polymorphic association
"Assignable" and "Assignments" are more natural to read than "peoplable"
class Person < ApplicationRecord
has_many :assignments, as: :assignable
has_many :roles, through: :assignments
end
class Role < ApplicationRecord
has_many :assignments
has_many :people, through: :assignments
end
class Assignment
belongs_to :role
belongs_to :assignable, polymorphic: true
end
You can read more Rails has_many :through Polymorphic Association by Sean C Davis
I have a products model and a variations model as a belongs_to association. There are some variations that absolutely belong to a single product, but there are others that can belong to many products. Can I create a join table on a belongs_to association like in a has_and_blongs_to_many association?
My Models Currently
product.rb
class Product < ApplicationRecord
has_many :variations, dependent: :destroy
has_and_belongs_to_many :categories
has_and_belongs_to_many :subcategories
include FriendlyId
friendly_id :name, use: :slugged
def should_generate_new_friendly_id?
name_changed?
end
end
variation.rb
class Variation < ApplicationRecord
has_and_belongs_to_many :categories
has_and_belongs_to_many :subcategories
belongs_to :product
include FriendlyId
friendly_id :name, use: :slugged
def should_generate_new_friendly_id?
name_changed?
end
end
From Rails guides association basics - the belongs_to association:
A belongs_to association sets up a one-to-one connection with another model, such that each instance of the declaring model "belongs to" one instance of the other model.
When you do the belong_to :product association on the Variation model, it expect to have a field named product_id which will point to the associated product.
use example:
variation = Variation.first
product = variation.product # this line will get the product which is associated to the variation by the product_id column.
Since it can hold only one integer (one product id) the best option is to restructure your code. It makes no sense to use a "belong_to" as "has_many" association.
You need to change the association to some king of many to many association.
To chose the best option for you, read and learn the differences in the Rails guides - Association Basics
*** Make sure you won't lose your data when changing the association:
Idea of doing that:
Create the join table
Copy the info from your variations table (the variation.id and the associated product_id)
Start using the new association
(You can probably copy the data in the migration file, just search how to do it)
There are three types of invoice items with following tables
1) SubscriptionItems,
2) Prorations,
3) UsageItems,
Those have the same attributes below
invoice_id
amount
stripe_invoie_id
However
only SubscriptionItem and Proration
period_start_at
period_end_at
and only Proration and UsageItem has
title
and only UsageItem has
uuid
account_id
description
To achieve this model I've been using polymorphic relation.
class InvoiceItem < ActiveRecord::Base
belongs_to :invoice
belongs_to :itemable, polymorphic: true
end
class SubscriptionItem < ActiveRecord::Base
belongs_to :plan
has_one :invoice_item, as: :itemable
end
class UsageItem < ActiveRecord::Base
belongs_to :account
has_one :invoice_item, as: :itemable
end
class Invoice < ActiveRecord::Base
belongs_to :account
has_many :invoice_items
end
class Account < ActiveRecord::Base
has_many :invoices
has_many :usage_items
end
For now it works.
However As far as I understand polymorphic should have has_many relation.
So this resides in the middle of Polymorphic and STI.
Because those three types of invoice items are always be subscriptionitem, proration, or usageitem.
It's hard decision that I could keep using this models (polymorphic with has_one) or should I use STI instead?
Or class table inheritance should be fit?
EDIT
I'd love to hear the reason why I could use some design.
Maybe those types pros and cons.
As far as I know,
If I apply STI
That leads many NULLable columns, but RoR supports STI. So it's easy
to use.
If I apply polymorphic with has_one
It stills the rails way but the original polymorphic definition is
different. It should have has_many relationship instead of
has_one. Also it's impossible to add foreign key.
Ref: Blog post for STI to polymorphic
If I apply Class table inheritance,
It's more efficient for relational database, but it's not rails way.
Ref: Blog post for STI to class table inheritance
I think STI with a hidden_field passing the appropriate value for each attribute that should determine the invoice type, could be the way to go here. It's simple and efficient.
Let's say you added a field called :invoice_type to your invoice model,
Then just loop through the items in an array like (Rough example):
<% #invoices.where(:invoice_type => "proration").find_each do |invoice| %>
<% #invoices.where(:start_date => "#{#invoice.start_date}").find_each do |invoice| %>
<!--Will only show the start_date of invoices where the invoice_type is propration. -->
<% end %>
<% end %>
I am working a side project where a user can have multiple clients. Those client can be of type Person or Business.
I was leaning toward the idea to using STI but I am not sure whether this is the right way to go since my models will not share the same attributes.
For instance a Business has a legal_form where a Person might have a marital_status.
Is it ok to use STI in this particular case or (2nd question) is there any way to allow rails to use separate tables for each types.
STI is like inheritance in ruby. You can use it if you have parent and children and they share a lot of attributes and data. If Person and Business share a lot you can use it. Otherwise I'd recommend you use Polymorphic Associations
A slightly more advanced twist on associations is the polymorphic
association. With polymorphic associations, a model can belong to more
than one other model, on a single association. For example, you might
have a picture model that belongs to either an employee model or a
product model. Here's how this could be declared:
class Picture < ActiveRecord::Base
belongs_to :imageable, polymorphic: true
end
class Employee < ActiveRecord::Base
has_many :pictures, as: :imageable
end
class Product < ActiveRecord::Base
has_many :pictures, as: :imageable
end
I don't really like STI and I'd recommend you try to use Polymorphic Associations.
A common problem with STI
A common problem with STI is that, over time, more types get added to
that table, and it grows more and more columns, and the records in the
table have less and less in common with one another. Each type of
record uses some subset of the table’s columns, and none uses all of
them, so you end up with a very sparsely populated table. Those types
create costs for one another: when you query for articles, you must
remember to filter out all the other types of values and to only
select columns relevant to articles, or else pay a huge performance
cost. You reproduce a lot of work the database would do for you, if
you only had each data type in its own table.
Assuming I would go for the polymorphic association would this be correct
class Client < ActiveRecord::Base
belongs_to :cliental, polymorphic: true
end
class Business < ActionRecord::Base
# Here I am using has_one because I do not want to have duplicates
has_one :client, as: :cliental
end
class Person < ActionRecord::Base
# Here I am using has_one because I do not want to have duplicates
has_one :client, as: :cliental
end
And later I would like to do the following
class User < ActiveRecord::Base
has_many clients
has_many businesses, through: :client
has_many people, through: :client
end
I've created 3 models:
Article: contains an article
Tag: contains tags
ArticleTag: meant for associating a many-to-one tags to article relationship. It contains a tag_id and an article_id.
The problem I'm having is I'm fairly new to the active record technology and I don't understand the proper way to define everything. Currently, which I think is wrong, is I have a
ArticleTag
belongs_to :article
belongs_to :tag
Now, from here my thought was to then add
Article
:has_many :tag
I'm not sure if im approaching this correctly at all. Thanks for the help!
It depends whether you want a join model or not. A join model lets you hold extra information against the association between two other models. For example, perhaps you want to record a timestamp of when the article was tagged. That information would be recorded against the join model.
If you don't want a join model, then you could use a simple has_and_belongs_to_many association:
class Article < ActiveRecord::Base
has_and_belongs_to_many :tags
end
class Tag < ActiveRecord::Base
has_and_belongs_to_many :articles
end
With a Tagging join model (which is a better name than ArticleTag), it would look like this:
class Article < ActiveRecord::Base
has_many :taggings
has_many :tags, :through => :taggings
end
class Tag < ActiveRecord::Base
has_many :taggings
has_many :articles, :through => :taggings
end
class Tagging < ActiveRecord::Base
belongs_to :article
belongs_to :tag
end
A Guide to Active Record Associations
You should use has_many when the relationship is one-way. An article has many tags, but tags also have many articles, so that's not quite right. A better choice might be has_and_belongs_to_many: an Article has many Tags, and those Tags also reference articles. A belongs_to B means that A references B; A has_one B means that B references A.
Here's a summary of the relationships you might see:
Article
has_and_belongs_to_many :tags # An article has many tags, and those tags are on
# many articles.
has_one :author # An article has one author.
has_many :images # Images only belong to one article.
belongs_to :blog # This article belongs to one blog. (We don't know
# just from looking at this if a blog also has
# one article or many.)
Off the top of my head, Article should be:
has_many :article_tags
has_many :tags, :through => :article_tags