Open arumoy-shome opened 7 years ago
After some reflection I find that we don't really need to save the term info. Really all we care about is the current term and we can easily retrieve it before the scheduled data update.
Subjects are worth saving since they won't change as frequently. This can be retrieved from the codes/subjects.
For each subject, we need to grab all the courses and save their schedule from the term/{term_id}/subject/schedule endpoint.
We also need to location info of the class which is nested within the schedule
object returned by the previous end point. We can pull this out into a separate model or keep in within Schedule, this can be thought of later.
Have been giving this some more thought and I see some limitations with the current model:
Subject
and Course
will heavily depend on this id to fetch all the relevant data.Term
as an active record model proposes another issue. Realistically, only a few subjects are taught each term. So a many_to_many
relation evolves here: subjects have_many
terms and terms have many subjects. Right now, we retrieve all the subjects and will need to do some filtering to get subjects belonging to the current term. This is just unwanted overhead which can be solved by simply making Term an ActiveRecord model.So, I have decided to make Term
an ActiveRecord model with just an id and description field and add a many to many relation between Term and Subject.
I came across a big factor that I have overlooked while designing Subject
and Course
, they are not linked with the current term. The whole point of making Term
a resource was so that we could distinguish between the subjects and courses available each term. This poses a design question: How do we link all Subject and Course records with the current term record?
Ideally, I would like to inherit from Term in my other resources so that I have the current term available to me and use STI. However we can't use this approach since our resources do not share the same columns. So the alternative here would be to treat Term as the parent/origin for all record creations internally. We can do this by adding simple delegator methods in Term that act as an interface for manipulating Subject and Course records. The implementation can then be placed in the corresponding resource this still preserving separation of concern.
I think a more robust solution would be to change how we have structured our model associations. In reality, we don't care much about the subject model. The focus is really on Terms and Courses (the API is also focused on these two resources). An alternative design would be to use a has_many :through
association, Terms has_many
Courses :through
Subjects.
* Term
has_many
courses* Course
has_many
terms* Subject
has_many
terms* Subject belongs_to
course (we are using belong_to instead of has_one because we want subject to hold the foreign key from course)
This will not work. The intermediate model needs to belong_to
both the other models which have a many to many relationship (Term and Course in this case) however, a subject, does not belong to a course. Rather, a course belongs to a Subject.
Simply put, we have the following models and relations:
Term --
has_many
--> Subjects --has_many
--> Catalog numbers --has_many
--> Classes/schedulesAs I reflect more on each model, I will post updates here.