gistfile1.txt

/*
  Since I have to go to the doctor tomorrow morning:

  There something Sandi Metz calls the "squint test" which means that 
  when you have to narrow your eyes to figure out what code is doing, you might have
  overcomplicated it.

  So I see you are very conversant with how to bend activerecord associations outside
  of their defaults.

  But if you are doing it SO much, you should stop and wonder if maybe something is off;
  You should not need to override class names and foreign keys, or explicitly specify them,
  so much.  In Rails there is usually a simple way to do 95% of the things.  When your
  code has a lot of frosting on it, you might be missing the simple way.

  The key is in your user model; I think in your mind there should only be one user model
  and you are thinking that the user will have one of two roles (or perhaps two roles at 
  the same time?)

  There is a principle called "Single responsibility" in object oriented programming and 
  it more or less means that one model cannot be both a caregiver and an employer because,
  in addition to the associations (which 50% of are meaningless for any one role) there
  will be other methods developing on the User model, lots of them, and half will 
  correspond to one type of user and half to another type.  This is why your associations are
  a little bit gnarly.  And if you look closely your validations are going to diverge also,
  significantly, from Caregiver to Employer.  They are distinct models.

  EITHER simply have two kinds of models that can each log in (this is NOT a crime) or maybe if
  that makes you uncomfortable create an Account model that is the login and nothing but
  that, and an account belongs_to an employer or a caregiver, or both.

  Now all of a sudden your associations feel natural.  an employer has jobs.  a caregiver has
  jobs.  an employer has reviews, a caregiver has reviews (if you want reviews to be left in 
  two directions, I suggest WAIT til later or have two different review type models like 
  EmployerReview and CaregiverReview and both employers and caregivers have_many of them.)
  Both have job_opportunities, both have favorites.  

  But anyway your associations make sense, don't require overrides....

*/



class Employer
  #these has_many relationships all assume the existence of employer_id on the related table
  has_many :jobs
  has_many :caregivers, through: :jobs
  has_many :job_opportunities
  has_many :reviews
  has_many :favorites

  # note that employer and caregiver have vastly different validation / verification requirements
  validates :first_name, :last_name, :gender, :email, :phone, :dob, :smoker, :address, :has_pets, presence: true 
end

class Caregiver
  #these has_many relationships all assume the existence of caregiver_id on the related table
  has_many :jobs
  has_many :employers, through: :jobs
  has_many :job_opportunities
  has_many :reviews
  has_many :favorited, class_name: 'Favorites', foreign_key: :caregiver_id

  # note that employer and caregiver have vastly different validation / verification requirements
  validate :validate_age
  validates :dob, presence: true

  private

  def validate_age
      if dob.present? && dob > 18.years.ago.to_i
          errors.add(:birth_date, 'You should be over 18 years old.')
      end
  end
end

class Job
  has_many :messages
end

class Message
  belongs_to :job
  belongs_to :employer
  belongs_to :caregiver
end