My model setup
class User < AR
has_many :books
...
end
class Book < AR
belongs_to :user
...
end
Books are in separate apartments and users are in the public schema.
I would like to add a shared model called assignment (to assign a book to a user) in the public schema that will have the following setup
class User < AR
has_many :books
has_many :assignments
...
end
class Book < AR
belongs_to :user
has_one :assignment
...
end
class Assignment < AR
belongs_to :user
belongs_to :book
...
end
The problem lies with the belongs_to :book portion in that the Assignment model is shared, giving no way to easily specify the schema that the book is in. There is also the possibility of id collisions among the books across different schemas which complicates the process further. As I see it I could:
1) Use scopes, specifying the apartment schema for the book
2) Use custom getters and setters for the book attribute in assignment, and fetch the required objects in the getter.
3) Put the assignment foreign key in the books model, which would be the simplest but not as clean (I want to be able to get the book_id/schema without a join)
4) Distribute the assignments model to the apartment schemas, which would be difficult as I must collect the assignments and sync them to an outside data source.
What is the best solution in this situation?
Related
I have two two models: Company and CompanyType. I need an association setup where a company can have and belong to many types. Based off the rails convention of naming join models I'm in sort've a bind. I can't name my join model CompanyType because that obviously exists. What do you do in these sort've situations?
class Company < ApplicationRecord
end
class CompanyType < ApplicationRecord
end
If you are not going to attach more stuff to it, you can skip creating the join model by defining a has_and_belongs_to_many association:
class Company < ApplicationRecord
has_and_belongs_to_many :company_types
end
class CompanyType < ApplicationRecord
has_and_belongs_to_many :companies
end
# No join model needed
You still need a migration to create the table though. See: http://apidock.com/rails/v4.2.1/ActiveRecord/Associations/ClassMethods/has_and_belongs_to_many
If you need the join model, you can follow the method explained in the same document, I guess.
I have many to many relation between users and projects through user_project. I know I could simply add has_many :projects in User Serializer (and vice versa in project serializer) to nest projects inside users.
But I also have a few additional fields in user_projects table (eg. start and end dates for user's participation in a corresponding project) and I have no idea what is the correct way to include them in the returned json. Should I create a special serializer for projects that are returned inside user with start_date included as a project's attribute or there's another way to do that?
The best way to do this would be to establish a 'has-many-through' (HMT) relationship between the user and project models and create a serializer for relationship's model.
class UserProjectSerializer < ActiveModel::Serializer
...
end
This will then be used in the UserSerializer via:
has_many :users_projects
The reason is that the relationship between the models contains additional data.
To implement the HMT, you'll need to create the user_projects model and define the HMT relationship in the related models:
users_project.rb
class UserProjects < ActiveRecord::Base
belongs_to :user
belongs_to :project
end
user.rb
class User < ActiveRecord::Base
has_many: users_projects
has_many: projects, through: :user_projects
end
project.rb
class Project < ActiveRecord::Base
has_many: users_projects
has_many: users, through: :user_projects
end
I have had a similar problem before and I made use of rabl. There is a good tutorial on railscasts to help you get started.
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'm trying to wrap my head around how I should model my database for a parent model with many has_one associations (20+). I have one model called House which is the parent model of all the other models:
class House < ActiveRecord::Base
has_one :kitchen
has_one :basement
has_one :garage
has_one :common_room
#... Many other child models
end
All the child models contain unique properties specific to their own class. I've thought about STI, but there isn't really any shared functionality or inputs that I can use across models. I've also thought of making one 'super model', but that doesn't really follow Rails best practices, plus it would contain over 200 columns. Is there another design pattern or structure that I can use to model this efficiently so that I can reduce database calls?
class House
has_many :rooms
Room::TYPES.each do |room_type|
has_one room_type, -> { where(room_type: room_type) }, class_name: "Room"
end
class Room
belongs_to :house
TYPES = %i/kitchen basement garage common_room etc/.freeze
end
In your migration make sure to add_index :rooms, [:type, :house_id], unique: true. Unless a house can have more than 1 type of room. If that is the case, I think a different approach is needed.
To your second question, it depends really, what type of database are you using? If its PostgreSQL you could use hstore and store those as a properties hash. Or you could serialize you db to take that as a hash. Or you could have another model that room has many of. For instance has_many :properties and make a property model that would store that information. Really depends on what else you want to do with the information
Why not using Polymorphism in Rails? It would be much simpler
class House < ActiveRecord::Base
has_many :properties, as: :property_house
end
class Kitchen < ActiveRecord::Base
belongs_to :property_house, polymorphic: true
end
class Garage < ActiveRecord::Base
belongs_to :property_house, polymorphic: true
end
For more information, go here: http://terenceponce.com/blog/2012/03/02/polymorphic-associations-in-rails-32/
I've got a rails application built for schools. The users in the system are parents who track their childrens’ activities (aka family members or just members). Teachers are also users and can log in to participate in activities. The Member model is the place that the application uses to find participants. So that teachers can be found they are added to the Member model and for the same reason, parents are added as well.
A teacher added to this application would have one record in each table user, user_member, and member. A record in user to allow him to login, 1 record in member so he can be searchable, and 1 in user_member to make the association. In this case finding a user’s own member record is trivial. But if I were a parent with a login and 2 children in the system, James and Brian, one would find 3 records in the Members table, one for James, one for Brian and one for myself. I need to know which member record is mine, not James or Brian.
What’s the best way to model this? I’ve considered two options 1) there’s a foreign key in the user table that points to a user’s own member_id OR 2) the user_members table has a boolean called ‘own_member’ which indicates this user_id’s member_id is the member record for the user. Is there one that would be preferable? One more rails like? And how would I make the call build/create the associations?
The current relationships are modeled like this:
class User < ActiveRecord::Base
has_many :user_members
has_many :members, :through => :user_members
end
class UserMember < ActiveRecord::Base
belongs_to :user
belongs_to :member
end
class Member < ActiveRecord::Base
has_many :user_members
has_many :user, :through => :user_members
end
It sounds like the UserMember join model describes which members a user has privileges to access. This is a different concept than tracking which Member record is associated to a particular user. It sounds like a user would have a member record, and a member would belong to a user implying the following database structure:
class User < ActiveRecord::Base
has_many :user_members
has_many :members, :through => :user_members
has_one :member
end
class UserMember < ActiveRecord::Base
belongs_to :user
belongs_to :member
end
class Member < ActiveRecord::Base
has_many :user_members
has_many :user, :through => :user_members
belongs_to :user
end
This means adding another database column to the members table for "user_id". Creating and building the member record from a User instance could be done as follows:
user = User.new
user.build_member
user.create_member
More info on building through associations here: http://ar.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html
You might consider creating callbacks to automatically create a member record on creation of a user record so you can skip manually building the associated record. An example would be:
# app/models/user.rb
class User < ActiveRecord::Base
before_create :build_member
def build_member
self.build_member
end
end
More information on callbacks here: http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html