Model instances with variable association. Is there a better way to do this?

Question

I have worked myself into a complex data structure, and I am wondering if there is a different pattern I should be using.

I have 4 models that are interdependent Shift , Day , Cluster , and Schedule .

• The Cluster has a date, and many Schedules .
• The Day has a Cluster that is most recent to the date of the Day (but not necessarily the same), and many Shifts .
• The Shifts are valid on the Day if the most recent Cluster has a Schedule that corresponds to the Shift .

There is no association between the Day and the Cluster , because I want to be able to add shifts to all the Days between the dates of the Clusters by simply adding a single Cluster .

My associations in app/models are abbreviated here:

class Cluster < ApplicationRecord
  has_many :schedules, dependent: :destroy
end

class Schedule < ApplicationRecord
  belongs_to :cluster
end

class Day < ApplicationRecord
  has_many :shifts
end

class Shift < ApplicationRecord
  belongs_to :day
end

I know that it would be easiest to eliminate the Cluster and Schedule classes entirely, and store the Schedule attributes directly on the Shift object, but if the start time changes, or a shift is added, I want all the affected shifts to automatically update without having to hit the database for each shift affected by that change.

class Day
  def cluster
    @cluster ||= Cluster.most_recent_to date
  end 
end

class Cluster
class << self
  def most_recent_to date
    find_by(date: date_most_recent_to(date))
  end

  def date_most_recent_to date
    date_comparison { |x| x <= date }.first
  end

  def date_comparison &date_comp
    all_dates.select(&date_comp)
  end

  def all_dates
    all.pluck(:date).sort.reverse
  end
end
end

The current structure works for what I am doing, but it is prone to error and corruption due to the inter-dependency of the classes.

Is there a better abstraction to represent a variable association between models?

Answer 1

Since your data structure is compressing a lot of potentially-redundant data into fewer rows, you're gaining the ability to quickly modify it in exchange for a tougher time reading it. And without suitable constraints, you can end up with nonsensical data, as you've probably found. However, if you unrolled your data as you mentioned and had just a list of Days with Schedules and Shifts for each, you might end up with even worse inconsistencies.

Two thoughts. First, I'd suggest adding more constraints into the mix. For example, it makes no sense to have two Clusters or two Days with the same date, right? So add validates_uniqueness_of:date to those models (and/or a unique DB constraint). There are probably other constraints you can think of, but without knowing your schema, it's hard for me to offer other suggestions.

Second, it saves you a little time to have Clusters dynamically attach to Days through their date attribute, but it might be causing you more trouble than it's worth. Consider having each Day belongs_to:cluster directly. To make up for the loss of ease in modifying schedules, update the UI with a form to quickly apply a given Cluster to a range of Days.

PS If you don't take my second suggestion, you can simplify your code a bit and avoid loading entire relations into memory ( all_dates is going to murder your performance as you scale) by leaning on the database in your calculations:

class Day
  def cluster
    @cluster ||= Cluster.where("date <= ?", date).order(date: :desc).first
  end 
end