Section type grade aggregation for Trends

[TyHil]

Overview

Trends is looking to add a new filter for grade data to aggregate based on section type. The UTD section types are as follows:

Section prefix	Meaning
0xx	Normal day lecture (before 5 PM)
0Wx	Online class
0Hx	Hybrid day class (online + face-to-face)
0Lx	LLC-only section
5Hx	Hybrid night class (online + face-to-face)
1xx	Lab section (sciences)
2xx	Discussion section (humanities)
3xx	Problem section (maths)
5xx	Night lecture (past 5 PM)
6xx	Lab night section (past 7 PM)
7xx	Exam section
HNx or HON	Honors-only

Changes

Currently Trends has a filter for semester which is why Trends uses the /grades/semester endpoint.

This issue is to create a new endpoint: /grades/semester/sectionType that returns grade data broken down by semester and then by section type within each semester. This would involve changes to the api/controllers/grades.go file.

Response format

/grades/semester response format

[
  {
    "_id": string, //ex 22S
    "grade_distribution": number[14]
  },
  ...
]

/grades/semester/sectionType response format

[
  {
    "_id": string, //ex 22S
    "data": [
      {
        "type": string, //ex 0xx
        "grade_distribution": number[14]
      },
      ...
    ]
  },
  ...
]

[mikehquan19]

This seems interesting. Can I work on this ?

[jpahm]

This seems interesting. Can I work on this ?

Definitely! This will likely involve setting up some more sophisticated aggregation pipelines since ideally we want to avoid needing to do any sort of schema changes to accommodate this.

[mikehquan19]

Hi @jpahm, I've made some significant progress in modifying the existing stages (if needed) and making additional stages for the section-type pipeline. It works as expected, but I have a few questions.

1/

Function gradesAggregation() is already long enough, so modification would make it even longer. Do you feel the need to modularize the function? Though I think modularizing function further would also be quite challenging since each part in the function is closely connected.

2/

You suggested that we want to avoid making any changes to schema. But then fields of the response wouldn't be in the desirable order. I have to add the following to grades_response.go:

type SectionTypeGradeResponse struct {
	Status      int           `json:"status"`
	Message     string        `json:"message"`
	OverallData []OverallData `json:"overall_data"`
}

type OverallData struct {
	Id   string          `bson:"_id" json:"_id"`
	Data []typeGradeData `bson:"data" json:"data"`
}

type typeGradeData struct {
	Type              string      `bson:"type" json:"type"`
	GradeDistribution interface{} `bson:"grade_distribution" json:"grade_distribution"`
}

The response then would be:

[
  {
    "_id": string, //ex 22S
    "data": [
      {
        "type": string, //ex 0xx
        "grade_distribution": number[14]
      },
      ...
    ]
  },
  ...
]

If I instead only used interface{}, the response would be:

[
  {
    "_id": string, //ex 22S
    "data": [
      {
        // the fields are swapped here (possibly not we want, I don't know)
        "grade_distribution": number[14], 
        "type": string, //ex 0xx
      },
      ...
    ]
  },
  ...
]

Do you think it's fine if I just need to use interface{} or I should keep the change ?

3/

Should the response have all section types listed even when some types have empty array? For example, the response to grades/semester/sectionType?first_name=Yi&last_name=Zhao would be:

{
            "_id": "23F",
            "data": [
                {
                    "type": "0xx",
                    "grade_distribution": [ ]
                },
                {
                    "type": "5xx",
                    "grade_distribution": [ ]
                }
            ]
},

because that semester only has 2 sections.

Thank you.

[jpahm]

Hey! Sorry about the slow reply, I've been buried in finals work recently.

1. Modularization isn't necessarily the goal, but we definitely want to minimize code re-use where possible. Any sort of structures that can be made to take a generalized input and produce a result accordingly should be split into their own functions. If something is too closely tied to specific functionality for that to be feasible, then it can be left alone. I'll leave this up to your discretion as it's ultimately a matter of opinion.

2. I probably should've been more clear about what I mean about not making changes to the schema -- I meant specifically the data schema, not the schema of response objects. Creating new response objects is completely okay and is an appropriate move to make here!

3. I'm going to defer to @TyHil on deciding this one, since this largely depends on what would work best for Trends.

[TyHil]

3. I'm going to defer to @TyHil on deciding this one, since this largely depends on what would work best for Trends.

I don't think it matters for Trends but I think removing the ones with empty arrays makes more sense since its not like we're sending empty arrays for every semester.

[mikehquan19]

Got it! Thank you all for the response. It should be taken care of as soon as I’m done with the finals.