Persistance Layer Design

[arumoy-shome]

Simply put, we have the following models and relations:

Term --has_many--> Subjects --has_many--> Catalog numbers --has_many--> Classes/schedules

As I reflect more on each model, I will post updates here.

[arumoy-shome]

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.

[arumoy-shome]

Have been giving this some more thought and I see some limitations with the current model:

1. We are not storing the term id. However, all the other models namely Subject and Course will heavily depend on this id to fetch all the relevant data.
2. Not having 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.
3. The biggest limitation I feel is the data loss that the current model will introduce in the long run. First off, when we retrieve the schedules, we will have to update the schedules of a course based on the term. With the proposed model, there will be a clear segregation between the schedules of the same course for different terms and we won't have to change the data in place.

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.

[arumoy-shome]

Term as single origin of all record creation

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.

August 19, 2017

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.