Ok, so I have three different objects: a person, place, and equipment. Each can have an address, in most cases multiple address and multiple phone numbers. So my thought is create the specific object tables, the have an address and a phone table. Here my question:
So typically, in my SQL world, I would just have an object_id column in the address and phone table and put a id of the object in the object id column, and then select all the address or phone records that match.
I could do this, do find_by_sql and get the records but I'd rather stay within the ActiveRecord paradigm. So does that mean I should have an id column in the table for each object, so a person_id, place_id, etc.
What's the "right" way to model this?
You can create polymorphic associations with activerecord, so you can add object_id and object_type to the addresses and phone_numbers tables, and specifying the associations like this:
class Address
belongs_to :object, :polymorphic => true
end
class PhoneNumber
belongs_to :object, :polymorphic => true
end
class Person
has_many :addresses, :as => :object
has_many :phone_numbers, :as => :object
end
class Place
has_many :addresses, :as => :object
has_many :phone_numbers, :as => :object
end
class Equipment
has_many :addresses, :as => :object
has_many :phone_numbers, :as => :object
end
This way, Person.first.addresses should run a query like Addresses.where(:object_type => "Person", :object_id => Person.first.id), and vice versa for the rest of the models and associations.
Related
I have a many to many :through relationship between a set of classes like so:
class Company
has_many :shares
has_many :users, :through => :shares, :uniq => true
end
class User
has_many :shares
has_many :companys, :through => :shares, uniq => true
end
class Share
belongs_to :company
belongs_to :user
end
I want to ensure a unique relationship so that a user can only have one share in any one company, which is what I have tried to achieve using the "uniq" argument.
At first I thought this was working, however it seems the behaviour os the "uniq" is to filter on the SELECT of the record, not pre-INSERT so I still get duplicate records in the database, which becomes an issue if I want to start dealing with the :shares association directly, as calling user.shares will return duplicate records if they exist.
Can anyone help with an approach which would force truely uniq relationships? so that if I try adding the second relationships between a user and a company it will reject it and only keep the original?
Have you tried adding this to your Share class?
validates_uniqueness_of :user, scope: :company
Also, in your User class I think it should be:
has_many :companies, through: :shares
I hope that helps.
I have a content model represented by class: content. Now users can rate content, review content or do both. I want to find all the content that a user have either rated, reviewed or rated and reviewed. The reviews table has a many-to-one association with the content table (meaning a content can be reviewed many times). A similar relationship exists between the ratings table and the content table.
I'm thinking I should do separate queries to find all rated content by a user, then all reviewed content by a user, then do a union. But I can't find out how to do a union that returns an active record relation. I need a relation because I want to paginate the results.
Thank you.
Ok, so first let's set up your models. From your explanation I'm thinking you'll want something like this:
class Content < ActiveRecord::Base
has_many :reviews
has_many :reviewing_users, :through => :reviews, :class_name => "User"
has_many :ratings
has_many :rating_users, :through => :ratings, :class_name => "User"
end
class User < ActiveRecord::Base
has_many :reviews
has_many :reviewed_contents, :through => :reviews, :class_name => "Content"
has_many :ratings
has_many :rated_contents, :through => :ratings, :class_name => "Content"
end
class Review < ActiveRecord::Base
belongs_to :content
belongs_to :user
end
class Rating < ActiveRecord::Base
belongs_to :content
belongs_to :user
end
And then for a given user you can find all the content that they've reviewed and/or rated with:
( user.reviewed_contents + user.rated_contents ).uniq
(user.reviewed_contents + user.rated_contents).uniq returns an array, not a relation, so beware. You can test this by attempting to call a class method on #posts (other than paginate).
You can still paginate though. just use #posts.paginate, as the will_paginate gem adds a paginate method to the array class.
I'm fairly new to ActiveRecord associations. I'm sketching out an application that tracks who owes each other money among a set of users. An Expense model and a User model seem like natural choices, I'm just not sure how to define the relationship between the two. For example, I want to track the creditor ("owner") and the debtor of each expense, but that's really just two foreign keys that go back to User. In addition, each user can have multiple expenses (both as creditor and debtor) My best guess for the associations thus far is something like:
class Expense
# belongs_to or has_one here?
# Not sure about class => User syntax:
# need to alias to foreign keys that reference the same model
belongs_to :creditor, :class => User
belongs_to :debtor, :class => User
class User
# has_many expenses defines a creditor relationship (user owns expense)
# how to define debtor relationship? (belongs_to...?)
has_and_belongs_to_many :expenses
I've read the Rails guide on associations but I'm still fairly lost on foreign keys and join tables. Any input is much appreciated!
So this is definately not a has_and_belongs_to_many thats for many-to-many relationships. You just need to use a couple has_many relationships. I think it should end up looking like this:
Edit: oops I fudged that a bit that up sorry let me have another go:
class Expense
# make sure expense table has 'creditor_id' and 'debtor_id' rows
belongs_to :creditor, :class_name => "User", :foreign_key => :creditor_id
belongs_to :debtor, :class_name => "User", :foreign_key => :debtor_id
class User
has_many :debts, :class_name => "Expense", :foreign_key => :debtor_id
has_many :credits, :class_name => "Expense", :foreign_key => :creditor_id
The other answers tell you what you need to do, but it can be kind of confusing to people who are new to Rails, as I am, to piece all these things together, so here is a complete solution, including both Migrations and Models.
Also, as a side note: I prefer Loans, Lender and Borrower to Expense, Creditor and Debtor, or Debt, Creditor and Debtor. Mostly because Expense is ambiguous and Debt is too similar to Debtor. But it's not that important; just do what makes sense to you, since you will be maintaing your code.
Migrations
class CreateLoans < ActiveRecord::Migration
create_table :loans do |t|
def up
t.references :lender
t.references :borrower
end
end
end
Here you are specifying that there are two columns in this table that will be referred to as :lender and :borrower and which hold references to another table. Rails will actually create columns called 'lender_id' and 'borrower_id' for you. In our case they will each reference rows in the Users table, but we specify that in the models, not in the migrations.
Models
class Loan < ActiveRecord::Base
belongs_to :lender, class_name => 'User'
belongs_to :borrower, class_name => 'User'
end
Here you are creating a property on the Loan model named :lender, then specifying that this property is related to the User class. Rails, seeing the 'belongs_to', will look for a column in the loans table called 'lender_id', which we defined above, and use that to store the foreign key. Then you're doing the exact same thing for the borrower.
This will allow you to access your Lender and Borrower, both instances of the User model, through an instance of the Loan model, like this:
#loan.lender # Returns an instance of the User model
#loan.borrower.first_name # Returns a string, as you would expect
As a side note: the 'belongs_to' nomenclature makes decent sense in this case, but can be kind of confusing elsewhere. Just remember that it is always used on whichever thing contains the foreign key.
class User < ActiveRecord::Base
has_many :loans_as_lender, :class_name => 'Loan', :foreign_key => 'lender_id'
has_many :loans_as_borrower, :class_name => 'Loan', :foreign_key => 'borrower_id'
end
Here you are creating a property on the User model named :loans_as_lender, specifying that this property is related to the Loan model, and that the foreign key on the Loan model which relates it to this property is called 'lender_id'. Then you are doing the same thing for :loans_as_borrower.
This allows you to get all the loans where a User is the lender or borrower, like this:
#address.loans_as_lender
#address.loans_as_borrower
Doing either of these will return an array of instances of the Loan model.
If your expense migration looks like this:
create_table :expenses do |t|
t.integer :creditor_id, :null => false
t.integer :debtor_id, :null => false
# other attributes here
end
then your Expense model is sufficient. If you take a look at the documentation for belongs_to, you'll see that it will correctly infer the foreign keys into the user table:
:foreign_key
Specify the foreign key used for the association. By default this is guessed to be the name of the association with an “_id” suffix. So
a class that defines a belongs_to :person association will use
“person_id” as the default :foreign_key. Similarly, belongs_to
:favorite_person, :class_name => "Person" will use a foreign key of
“favorite_person_id”.
So you don't need to explicitly specify a foreign key here. If you use other naming conventions for the ids in your expenses model, then you need to explicitly specify them in your associations.
For your User model, you don't have a many_to_many relationship with expenses - an expense always belongs to exactly one debtor and exactly one creditor. So all you need is two has_many associations:
has_many :debts, :class_name => 'Expense', :foreign_key => :debtor_id
has_many :credits :class_name => 'Expense', :foregin_key => :creditor_id
I have an application which has projects and users. I don't care about tracking the many-to-many relationships between users and projects but I am interested in tracking the many-to-one relationship between projects and a specific user, which is the project manager. Ideally, I would like to create a column in the projects table called projectmanager_id and link it to a user. However, rails convention dictates that I use user_id instead. While this works, I feel the semantics aren't quite right. Is there a way to have both?
One way I thought of is to create a projectmanagers table with user_id and project_id and have a has_many :projects, :through=> :projectmanagers in the user model, and has_one :user, :through => :projectmanagers in the project model. Is there a better way?
You could try this if you keep the db column as user_id:
In your project.rb file:
belongs_to :projectmanager, :foreign_key => "user_id", :class_name => "User"
And in your user.rb file still have:
has_many :projects
Or if it's that you want your db column to be projectmanager_id
In your project.rb file:
belongs_to :projectmanager, :foreign_key => "projectmanager_id", :class_name => "User"
In your user.rb file:
has_many :projects, :foreign_key => "projectmanager_id", :class => "Project"
I'm trying to understand how ActiveRecord deals with associations that are more complex than simple has_many, belongs_to, and so on.
As an example, consider an application for recording music gigs. Each Gig has a Band, which has a Genre. Each Gig also has a Venue, which has a Region.
In the rough notation of MS Access (which I'm suddenly beginning to feel quite nostalgic for) these relationships would be presented like this
1 ∞ 1 ∞ ∞ 1 ∞ 1
Genre ---- Band ---- Gig ---- Venue ---- Region
I would like to be able to find out, for example, all the bands who've played in a region, or all the venues that host a certain genre.
Ideally, my models would contain this code
class Genre
has_many :bands
has_many :gigs, :through => bands
has_many :venues, :through => :gigs, :uniq => true
has_many :regions, :through => :venues, :uniq => true
end
class Band
belongs_to :genre
has_many :gigs
has_many :venues, :through => :gigs, :uniq => true
has_many :regions, :through => :venues, :uniq => true
end
class Gig
belongs_to :genre, :through => :band
belongs_to :band
belongs_to :venue
belongs_to :region, :through => :venue
end
and so on for Venue and Region.
However, it seems I have to produce something like this instead
class Genre
has_many :bands
has_many :gigs, :through => bands
has_many :venues, :finder_sql => "SELECT DISTINCT venues.* FROM venues " +
"INNER JOIN gigs ON venue.id = gig.venue_id " +
"INNER JOIN bands ON band.id = gig.band_id " +
"WHERE band.genre_id = #{id}"
# something even yuckier for regions
end
class Band
belongs_to :genre
has_many :gigs
has_many :venues, :through => :gigs, :uniq => true
# some more sql for regions
end
class Gig
delegate :genre, :to => :band
belongs_to :band
belongs_to :venue
delegate :region, :to => :venue
end
I have two questions - one general and one particular.
The general:
I would have thought that what I was trying to do would come up fairly often. Is what I have really the best way to do it, or is there something much simpler that I'm overlooking?
The particular:
What I have above doesn't actually quite work! The #{id} in the second genre model actually to return the id of the class. (I think). However, this seems to work here and here
I realise this is a rather epic question, so thank you if you've got this far. Any help would be greatly appreciated!
Associations are designed to be readable and writable. A large part of their value is that you can do something like this:
#band.gigs << Gig.new(:venue => #venue)
It sounds, though, like you want something that's read-only. In other words, you want to associate Venues and Genres, but you'd never do:
#venue.genres << Genre.new("post-punk")
because it wouldn't make sense. A Venue only has a Genre if a Band with that particular Genre has a Gig there.
Associations don't work for that because they have to be writable. Here's how I'd do readonly associations:
class Genre
has_many :bands
def gigs
Gig.find(:all, :include => 'bands',
:conditions => ["band.genre_id = ?", self.id])
end
def venues
Venue.find(:all, :include => {:gigs => :band},
:conditions => ["band.genre_id = ?", self.id])
end
end
You can add conditions and parameters to your associations.
Recent versions of ActiveRecord give the power of named_scopes, which will work on associated records as well.
From a current project
Folder has_many Pages
Page has_many Comments
# In Page
named_scope :commented,
:include => "comments",
:conditions => ["comments.id IS NULL OR comments.id IS NOT NULL"],
:order => "comments.created_at DESC, pages.created_at DESC"
Using this we can say:
folder.pages.commented
Which will scope on the associated records, doing a conditional with the supplied parameters.
Plus! named_scopes are composable.
And more scopes:
named_scope :published, :conditions => ["forum_topics.status = ?", "published"]
And chain them together:
folder.pages.published.commented
For associations like this, you're going to end up writing custom SQL -- there's no real way that you can handle a chain of associations like this without having to do some fairly massive joins, and there really isn't an efficient way for the built-in query generators to handle it with a one-liner.
You can look into the :joins parameter of ActiveRecord as well -- this may do what you want.
Sounds like a job for nested_has_many_through! Great plugin that allows you to do nested has_many :throughs