I have a model "entry" and I need it to act like a list when a playlist_id is specified, but if it's not, I need it to not act like a list. (acts_as_list is a gem I'm using)
In my model code I have:
acts_as_list scope: :playlist
I need to figure out the best way to do this. I'm thinking of subclassing a model maybe, but I'd prefer to just keep it as one model but add this additional logic. I don't know the order of initialization for active_record so I'm not sure where I could mess with things like this and where I can't.
(The reason why I need to do this: I want to have loose items that belong to another model, simply sorted by date. As my "default list" has grown in size, I'm experiencing some performance issues since we have to look up the last entry in a list to know the position of the newest item.)
My shallow understanding is the model projection may need improvement. In my understanding act_as_list is better for has_many - belongs_to relationship, say a todo is exactly in a Todo list.
But in your case, let's say the entry is a song. A playlist can have many songs and a song can belongs to many playlist. So the relationship is many to many.
I think you need an intermediate model say ListItem to represent such relationship
class PlayList < ActiveRecord::Base
has_many :list_items
has_many :entries, through: :list_items
end
class ListItem < ActiveRecord::Base
belongs_to :play_list
belongs_to :entires
acts_as_list scope: :play_list
end
class Entries < ActiveRecord::Base
has_many :list_items
has_many :play_lists, through: :list_items
By this design, what you sort on PlayList is only the list items, not the entries. Performance should be improved a lot as longs as on playlist doesn't contain too much list_items, which should be common.
Related
I was interested in creating a model that could stand alone but could also belong to another model. So for example: I have an Artist that has many Albums. In addition to having many tracks (which is irrelevant for this case) it also can have many Singles. Here's the catch. There are some instances where a single doesn't belong to an album and is just used for promo (aka a promo single). So I thought I'd approach it using a polymorphic association:
class Artist < ActiveRecord::Base
has_many :albums
has_many :singles, as: :singleable
end
class Album < ActiveRecord::Base
belongs_to :artist
has_many :singles, as: :singleable
end
class Single < ActiveRecord::Base
belongs_to :singleable, polymorphic: true
end
Not being entirely familiar with polymorphic associations I didn't know if this would be the correct way to setup what I had in mind of doing. Alternatively should I have created an entirely separate model called PromoSingle or create a dropdown that would define the single type?
I don't think this case actually needs a polymorphic association. It should work, yes, but you'll soon find yourself in situations when you need to perform complicated searches to get seemingly simple results.
Polymorphic association should be used when association is semantically the same, but may involve different objects. It's not the case here, an artist is the one who created the track. But the album isn't.
This can cause trouble at least if you ever decide to fetch specific artist's tracks. Here's what ActiveRecord would have to do with your structure (including internal operations):
Get list L1
Get an array A of album_ids, whose artist_id is X (a parameter)
Get all singles, whose singleable_type is "Album" and singleable_id is in the array of albums A, fetched before.
Get list L2
Get all singles, whose singleable_type is "Artist" and singleable_id is X.
Concatenate L1 and L2
Here is what I suggest you do.
class Artist < ActiveRecord::Base
has_many :albums
has_many :singles
end
class Album < ActiveRecord::Base
belongs_to :artist
has_many :singles
end
class Single < ActiveRecord::Base
belongs_to :artist
belongs_to :album
end
PromoSingles fit well here too. Just because association is defined doesn't mean it should be present: it only means "it might be present, there is a place where we can put it".
Should you absolutely need it to be present (not here, somewhere else), you'd use a validation to ensure.
Otherwise, you may have items that don't belong to anyone, or, technically, belong to nil (Ruby level) or NULL (DB level). It's not bad if it makes sense.
Using Rails 4 (and Postgres), I'm trying to work out the best way in which to structure my ActiveRecord associations and corresponding database tables/relationships for a diet tracking app.
I want my app to be structured as follows:
I have Document and FoodEntry models. Each Document has a number of FoodEntries. I want to be able to iterate over them like document.food_entries.each ... (which is easy with your typical has_many association).
However all the FoodEntries for each Document need to be able (potentially but not necessarily) to be subdivided by day, as this is a natural division for which logic and calculations must be able to be performed, in addition to doing them for the whole document. For instance I'd be using something like document.day(1).food_entries.each ....
Furthermore, each day should be able to be subdivided (again, optionally) into meals in a similar manner, e.g. document.day(1).meal(1).food_entries.each ...
Lastly, there must be a way to record the user-specified order that the FoodEntries, meals, and days are in for each document. Presumably using number sequence(s)?
I was thinking there are a few ways I could do this:
Use a simple has_many relationship. Have day, meal and sort columns in the food_entries table, where the value for day and meal is left blank or given a default value if a day/meal isn't provided. Use a logic-based approach to get and sort the entries for a day or meal.
Outline:
class Document
has_many :food_entries
class FoodEntry
belongs_to :document
Potential issues:
This might leave things a bit messy in general in the table?
All the logic for subdividing things would have to be hand-coded.
Storing/using the user-defined (i.e. arbitrary) sort order might get a bit complicated? The order for entries AND days AND meals would have to stored in and inferred from one sequence (unless more columns were added).
Use has_many :through to set up associations through days and meals (naming?) tables. Entries where a day/meal isn't specified get given a default. Both these tables have their own individual sort column, along with the food_entries table.
Outline:
class Document
has_many :days
has_many :meals, through: :days
has_many :food_entries, through: :days (AND :meals???)
class Day
belongs_to :document
has_many :meals
has_many :food_entries, through: :meals
class Meal
belongs_to :day
has_many :food_entries
class FoodEntry
belongs_to :meal
Potential issues:
Adds unnecessary relational complexity? (consider that days or at the very least meals are meant to be optional)
Can I even use has_many :food_entries through: ... in my Document model if it would have to go through both tables?
A compromise between the two approaches above: have a days table but keep meal in a column in the food_entries table.
Something else? Polymorphic association(s)?
This is getting a bit complicated to wrap my head around, and so I'm really having a hard time working out what I should use. What is the correct way to go about things?
A couple of final questions which are related but completely optional:
Ideally the day value could be either a datetime value or an arbitrary string, depending on what the user sets. Is this possible?
Could anyone point me to a resource that can inform me about sorting/ordering strategies? Like I said I assume the simplest way is to use a sequence of numbers, but I'm not exactly sure how I would work with such a sequence.
has_many :through
You'd only use a has_many :through relationship if you wanted to attribute multiple FoodEntries to Document, like this:
#app/models/document.rb
Class Document < ActiveRecord::Base
has_many :food_entries_types
has_many :food_entries, through: :food_entries_types
end
#app/models/food_entry_type.rb
Class FoodEntryType < ActiveRecord::Base
belongs_to :document
belongs_to :food_entry
end
#app/models/food_entry.rb
Class FoodEntry < ActiveRecord::Base
has_many :food_entries_types
has_many :documents, through: :food_entries_types
end
This would only allow you to associate many food_entries with a similar number of documents. Although you could add specific days & meals attributes to the join model, allowing you to call them as required
Scopes
I believe a much better option for you is to use ActiveRecord scopes:
#app/models/document.rb
Class Document < ActiveRecord::Base
has_many :food_entries
#uses [wday][3]
#needs to return dates for specific day
scope :day, ->(day = 1) { where(created_at: Date::DAYNAMES[day]) }
scope :meal, ->(meal = 1) { where(meal: meal) }
end
Because scopes can be chained, I believe you'd be able to do this:
food = Document.day(1).meal(2).food_entries
Class Method
You could also create a class_method to achieve something similar:
#app/models/document.rb
Class Document < ActiveRecord::Base
has_many :food_entries
def self.sorted(day = 1, meal = 1)
document = self.where("created_at = ? AND meal = ?", Date::DAYNAMES[day], meal)
end
end
#app/controllers/documents_controller.rb
def show
#document = Document.sorted
end
I ended up implementing my #2 option. This has given me the most flexibility and worked out well. I think it has been the most elegant approach for my use case.
I'm new to rails and I'm trying to associate a default song with a theme. The problem is if I give the theme a default_song_id attribute, I can only access the song directly with a call to default_song if I make the theme belong_to the song.
My problem with this is basically just the name of the association. The theme obviously doesn't belong to the song in the hierarchy of my models, and the songs have too many attributes already. It doesn't make sense to give songs a theme_id attribute as the songs are involved in plenty of other relations and it really is just the theme that cares about a particular song, plus one song can be referenced by multiple themes.
So do I have any other options?
It sounds as though the 'has_many :through' association might be what you're looking for. There's a great run-through here: http://guides.rubyonrails.org/association_basics.html.
Essentially, you're going to want to set up an intermediary model to join your Song and Theme models without making one explicitly belong to the other. Say you create an "Assignment" model to handle this, your models would say:
class Song < ActiveRecord::Base
has_many :assignments
has_many :themes, through: :assignments
end
class Theme < ActiveRecord::Base
has_many :assignments
has_many :songs, through: :assignments
end
class Assignment < ActiveRecord::Base
belongs_to :song
belongs_to :theme
end
For each pairing you then have an Assignment with a theme_id and a song_id so you can always query the Assignments table where theme_id/song_id = x to retrieve either associated record. Hopefully this approach is flexible enough to do what you're trying to do.
As concerns using another name for the association definition: No.
Rails is an opinionated framework, by design - convention over configuration. belongs_to is the keyword its designers have chosen for this concept in the DSL of model/association descriptions, and you should try to get used to using it. Try to keep in mind that what you're writing is still code; just because a lot of Ruby/Rails reads like English, that does not mean it is English, and keywords aren't always going to have the same meaning as the English words they look like.
It is theoretically possible to alias belongs_to and the other association macros, but you really shouldn't. It will harm the readability of your code if anyone else ever has to use it.
I have read the Choosing Between has_many :through and has_and_belongs_to_many on the Rails website, however I am a bit confused since I have a different case to the ones given on the website.
I have two models: Prop and CharacterCostume, and the character's costume can have multiple props associated to it, but a prop doesn't belong to that character and it can be used by any number of characters in the scene, too.
Right now I have has_and_belongs_to_many :props inside my CharacterCostume model, which does exactly what I want it to do: it fetches all the props associated with the costume using a table named character_costumes_props when I call CharacterCostume#props
However the association name is putting me off because of the "belongs to many" part. The costume does not belong to any of the props, so there's no has_and_belongs_to_many :character_costumes inside the Prop model.
I know that it can all function fine without it, but it got me thinking that maybe I should use a has_many :through association, but that requires me to create a superfluous model (it is superfluous, right?) and the model would look like this:
class CharacterCostumeProp < ActiveRecord::Base
belongs_to :character_costume
has_one :prop
end
Also, would has_one instead of belongs_to work here?
I want the code to be as semantic as possible, but I am not sure if this will increase the requirement for resources or decrease performance in some way, since there's an intermediate model.
Are there certain quirks/benefits attached to either approach? Is mine good enough? Or is my thinking completely wrong from what I need to do?
Thanks!
I think you want to use a :has_many, :through because you're going to want to work directly with the relation model - what scene(s), consumed or damaged, etc.
But, the reason it reads funny to you is that, for the most part, has_many and belongs_to don't really mean what they mean in English. What they really mean is "They have the foreign keys" and "I have the foreign key", respectively; the exception being the :dependent => :destroy behavior.
That still doesn't really help with has_and_belongs_to_many, since you're then saying, "They have the foreign keys and I have the foreign keys` - except that you can think of it sort of adding a new part both to "I" and "They" that happens to be the same part for each, and has those keys.
Does that help?
The single most important question you must ask yourself when deciding between HABTM and has_many :through is this:
Do I want to store any information specific to the association?
Example 1: magazine subscriptions
A many-to-many relationship between readers and magazines might conceivably be structured as a HABTM or a has_many :through. However, the latter makes far more sense in this case because we can easily think of information specific to the association that we might want to store.
A reader is related to a magazine through a subscription, and every subscription can be described by fields such as price, starting date, issue frequency and whether it's active or not.
Example 2: tags
The relationship between an existing Tag model and, say, an Article model is clearly of the many-to-many kind. The fact that one particular tag has been associated to any particular article must have no influence on whether the same tag will be able to be similarly associated to other articles in the future.
But, differently from the previous example, here the association itself is all the information we need. We just need to know which tags are associated to any given article. It doesn't matter when the association was formed. It doesn't matter how long it lasted.
It may matter to us how many articles a tag is associated with. But that information is stored in the Tag model since it's not specific to an association. There is even a Rails feature that takes care of that called counter_cache.
has_one wouldn't work, you'd need belongs_to
it is not superfluous if you have logic in your association model
has_and_belongs_to_many is good enough for you
See example below
class Student
has_and_belongs_to_many :courses
has_many :teachers, through: :courses
end
class Teacher
has_many :courses
has_many :students, through: :courses
end
class Course
has_and_belongs_to_many :students
belongs_to :teacher
def boring?
teacher.name == 'Boris Boring'
end
end
In the example above, I make use of both versions. See how Course would have its own logic? See how a class for CourseStudent might not? That's what it all comes down to. Well, to me it is. I use has_many through for as long as I can't give a proper name to my association model and/or the model doesn't need extra logic or behavior.
I'm a beginning to ROR, but here's what I'm trying to achieve. I have two items I want to associate: matters and people. Each matter can have many people. That is, I want to create people and matters separately and later be able to link them.
For example, I may create:
Bill Clinton
Barack Obama
I may create the matters:
Global warming
War on terror
I want to be able to associate the users Bill Clinton AND Barack Obama to BOTH matters. Can someone point me to a tutorial that can show me how to do this?
I think has_and_belongs_to_many is used less and less by the RoR community now. While still supported, I think it is now more common to have an intermediate model (in your case something like PoliticianMatter) to join your Politician and Matter models.
Then your politician_matter table will have a PK, a politician_id and a matter_id.
Then you have
class PoliticanMatter < ActiveRecord::Base
belongs_to :politician
belongs_to :matter
end
The advantage of this approach is that if there ever need to be future properties of the politician -> matter relationship (e.g importance, date of last occurrence) you have a model which affords this - has_and_belongs_to_many would not support the addition of these extra properties.
You can also access the many to many relationship directly from the Politician and Matter models like this
class Politician < ActiveRecord::Base
has_many :politician_matters
has_many :matters, :through => :politician_matters
end
class Matter < ActiveRecord::Base
has_many :politician_matters
has_many :politicians, :through => :politician_matters
end
You need a many2many relationship between these two entities.
A matter can be studied by many people
A person can studie several matters
Rails uses the has_and_belongs_to_many helper to do that. You'll find more about that in the documentation and many many blog posts!
has_and_belongs_to_many helper
class Politician < ActiveRecord::Base
has_and_belongs_to_many :tasks
end
class Task < ActiveRecord::Base
has_and_belongs_to_many :politicians
end
What you need are 3 tables:
politicians, tasks and politicians_tasks (having the two columns politician_id and task_id, no primary key)
Hope this helps
Seb