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.