Hello Everyone,
I have a polymorphic association currently in use with a few different models. Each model has it's own video file associated with it, so it uses a "videoable" polymorphic association. I recently found the need however, to create a new model that has 2 separate types of videos. I will let the code do the talking.
#current setup
class Video < ActiveRecord::Base
belongs_to :videoable, :polymorphic => true
end
class Project < ActiveRecord::Base
has_one :video, :as => videoable
end
# New model I am working on
class Assignment < ActiveRecord::Base
has_one :video_draft
has_one :video_final
end
Ideally the assignment model would have two special types of video objects while still using the polymorphic association. I have considered single table inheritance, but I am not sure that is the best approach here. What are my options? I do not want to create a video_draft model and a video_final model because in the end, they are just video attachments like everything else. The only difference is that they are specialized video attachments that need their own unique reference.
What you need to do is to tell ActiveRecord what model are you referring to when declaring :video_draft instead of :video like in Project model. This can be done by passing :class_name option to has_one
Keeping this in mind, this should work fine:
class Assignment < ActiveRecord::Base
has_one :video_draft, :as => :videoable, :class_name => "Video"
has_one :video_final, :as => :videoable, :class_name => "Video"
end
See rails guides at section 4.2.2.3 for more info about need for passing :class_name.
Related
I have a problem or dilemma after implementing polymorphic association following this: All the code is located here,
I have implemented this model:
Let's suppose that I also need the subscription to magazines. It will also be something similar to the other two
class Magazines < ApplicationRecord
has_many :subscriptions, as: :subscribable
end
class User < ApplicationRecord
has_many :subscriptions
has_many :podcasts, through: :subscriptions, source: :subscribable, source_type: 'Podcast'
has_many :newspapers, through: :subscriptions, source: :subscribable, source_type: 'Newspaper'
has_many :magazines, through: :subscriptions, source: :subscribable, source_type: 'Newspaper'
end
class Subscription < ApplicationRecord
belongs_to :subscribable, polymorphic: true
belongs_to :user
end
It works well, the problem now is ok I can handle like three types of subscription
MagazineSubscription, PodcastSubscription and NewspaperSubscription. The three have the same attributes and same behaviour, but belongs to different model. What happens If after doing that I need some kind of MTI or STI with the subscription classes. i.e. the MagazineSubscription have different behaviour and maybe other attributes. There is an easy way on this to accomplish this new requirement like creating a Subscription class that handles all that the polymorphic association and the other models:
class Subscription < ActiveRecord::Base
self.inheritance_column = :sti_subscription
belongs_to :subscribable, polymorphic: true
belongs_to :user
def _type=(sType)
sti_subscrition = sType.to_s.classify.constantize.base_class.to_s + "Subscription"
super(sType.to_s.classify.constantize.base_class.to_s)
end
end
class MagazineSubscription < Subscription
# new behaviour here
end
or I must follow something similar to this with the Subscription class handling two polymorphic relations, with the subscribable and his descendants
So my question is when I have used polymorphic association is an easy way to use that to set STI or MTI, or I need to make a new approach
I am designing a database of woodwind instrument sounds, and would like to create a table that joins pairs of sounds that a performer can combine into, for example, a trill. Such relations are transitive: if sound A has a 'Sound Relation' with sound B, then sound B has that same 'Sound Relation' with sound A.
I am familiar with join tables, but I've never seen them used to join 'like' objects, only to join 'unlike' objects, such as tags and posts, so I'm wary of going that direction.
I realize the example below looks extremely dubious, but it gives an idea of what I'm after. What is a better way of doing it? (Using ActiveRecord syntax)
Models
class Sound < ActiveRecord::Base
has_many :linked_sounds, through: :sound_relations, class_name: "Sound", foreign_key: ???
end
class Sound_Relation < ActiveRecord::Base
has_many :sounds
end
Migration
class CreateSoundRelations < ActiveRecord::Migration
def change
create_table :sound_relations do |t|
t.integer first_sound_id # This cannot possibly be right.
t.integer second_sound_id # Surely the transitivity of the
# relationship should be more evident?
end
end
end
You might try something like:
class Set < ActiveRecord::Base
has_many :sound_sets
has_many :sounds, :through => :sound_sets
end
class SoundSet < ActiveRecord::Base
belongs_to :sound
belongs_to :set
end
class Sound < ActiveRecord::Base
has_many :sound_sets
has_many :sets , :through => :sound_sets
has_many :set_sound_sets, :through => :sets , :source => :sound_sets
has_many :set_sounds , :through => :set_sound_sets, :source => :sound
end
So, no more "sound_1" and "sound_2" ... they are both just sounds. For every sound you can also use the set_sounds method to retrieve all of the sounds associated with it.
This would also allow more than two sounds in a relation, and you might like to put a "type" on the sets model.
Edit: If you look at the query generated, you'll find that sound_sets is mentioned in there twice, once with a different alias. The key to eliminating "self" joins is to include a clause in the association along the lines of:
has_many :set_sounds ,
{where("sound_sets.sound_id != set_sound_sets_sound_set_sounds.sound_id")},
:through => :set_sound_sets,
:source => :sound
... where "sound_set_sounds" is the table alias. If you can post the query in the comments I can update this with the actual alias.
So I think I need help with what I am doing with my asscoiations. I have two models (well many but for the purposes here). One is a Provider. Each provider can have a designation. Though the Designations is just a list it can appear in many different providers so it is not one to one. My models are as follows:
Provider.rb
class Provider < ActiveRecord::Base
has_and_belongs_to_many :groups
has_one :designation
has_one :specialty
end
Designation.rb
class Designation < ActiveRecord::Base
end
The error I get is this:
SQLite3::SQLException: no such column: designations.provider_id: SELECT "designations".* FROM "designations" WHERE "designations"."provider_id" = ? LIMIT 1
Which tells me my associations are off cause the designations should not have the provider_id, if anything the provider should have the designation_id.
Do I ditch the has_one and just put has_many in the Designation?
If I do that, I am new to rails, do I have to create a migration so the database is correctly updated?
Try using
models/provider.rb
belongs_to :designation
Then in
models/designation.rb
has_many :providers
It may feel a little strange but the belongs_to just lets you know which model the id column needs to go in. In this case the provider model, so you'll need:
rails g migration add_designation_id_to_provider designation_id:integer
An example of my issue is a sports game. A sports game has two teams, a home team and an away team. My active record models are as follows:
class Team < ActiveRecord::Base
belongs_to :game
end
class Game < ActiveRecord::Base
has_one :home_team, :class_name => "Team"
has_one :away_team, :class_name => "Team"
end
I want to be able to access a team through the game, for example: Game.find(1).home_team
But I am getting an unitialized constant error: Game::team. Can anyone tell me what I'm doing wrong? Thanks,
If Game has_one :team then Rails assumes your teams table has a game_id column. What you want though is for the games table to have a team_id column, in which case you'd use Game belongs_to :team. As English it does sound backwards in this case, but as Ruby, it's correct.
I did simplify a little. You'd want something like:
class Team < ActiveRecord::Base
has_many :home_games, :class_name => "Game", :foreign_key => 'home_team_id'
has_many :away_games, :class_name => "Game", :foreign_key => 'away_team_id'
end
class Game < ActiveRecord::Base
belongs_to :home_team, :class_name => "Team"
belongs_to :away_team, :class_name => "Team"
end
I just tested your code and it should work.
What I suspect is that your file name is wrong. Make sure that your filenames in app/models/ are:
game.rb
team.rb
and not:
games.rb
or
teams.rb
I think that it may be a mistake of your architecture.
Game can't distinguish two Team with this architecture.
So, please run like that
rails g migration add_stadium_to_game stadium:integer
rails g migration add_home_to_team home:integer
rake db:migrate
and, edit "game.rb" like that
class Game < ActiveRecord::Base
has_many :teams
def home_team
teams.select { |team| team.home == self.stadium }.first
end
def away_team
teams.select { |team| team.home != self.stadium }.first
end
end
Of cource this is one example, so there are many ways to realize your purpose.
Sounds like a namespacing problem. Try explicitly declaring the class (with namespace) for team. E.g.:
has_one :home_team, :class_name => "::Team"
http://guides.rubyonrails.org/association_basics.html#the-has_one-association
I'm trying to figure out the best way to setup my database and models for the following scenario.
A user can like an infinite number of songs.
A song can be liked once by an infinite number of users.
I have these tables:
songs, users, likes etc... Following RoR conventions.
The table named likes has these foreign keys: user_id, song_id. And also a field named 'time' to save a timestamp when the song was liked.
I'm not sure of how to do this, I would like to be able to use code like this in my controllers:
User.find(1).likes.all
This should not return from the likes table, but join the songs table and output all the songs that the user likes.
What are the best practises to achieve this in Ruby on Rails following their conventions?
Unless you need to act specifically on the likes table data, the model itself is probably not necessary. The relationship is easy:
class User < ActiveRecord::Base
has_and_belongs_to_many :songs
end
class Song < ActiveRecord::Base
has_and_belongs_to_many :users
end
This will join through the currently non-existent song_users table. But since you want it to join through likes you can change each one to this:
has_and_belongs_to_many :songs, :join_table => 'likes'
If you want to be able to call User.find(1).likes and get songs, then change the user's version to this:
class User < ActiveRecord::Base
has_and_belongs_to_many :likes, :join_table => 'likes', :class_name => 'Song'
end
And you could change the songs version to something like this:
class Song < ActiveRecord::Base
has_and_belongs_to_many :liked_by, :join_table => 'likes', :class_name => 'User'
end
This will give you Song.find(1).liked_by.all and give you the users (You could keep it to users if you wanted using the first version)
More details on habtm relationships can be found here: http://apidock.com/rails/ActiveRecord/Associations/ClassMethods/has_and_belongs_to_many
Edit to add
If you want to act on the join table for whatever reason (you find yourself needing methods specifically on the join), you can include the model by doing it this way:
class User < ActiveRecord::Base
has_many :songs, :through => :likes
has_many :likes
end
class Like < ActiveRecord::Base
belongs_to :user
belongs_to :song
end
class Song < ActiveRecord::Base
has_many :users, :through => :likes
has_many :likes
end
This will let you do User.find(1).songs.all, but User.find(1).likes.all will give you the join data