Feat/search bar/backend

[ElaineShu0312]

Implemented search.py, which has the following functionality:

What we can search for, with "query" or "student_absences":

• student first/last name
• mentor first/last name
• student email
• mentor email
• student absences (range or exact)

What it should return:

• all students that match the query
• the associated sections that have the students in them

E.G. if you query student_absences=4, the JSON will look like:

        {
            "id": 91,
            "spacetimes": [
                {
                    "startTime": "22:48:46.548833",
                    "dayOfWeek": 4,
                    "location": "Moffitt 300",
                    "id": 135,
                    "duration": 3600.0,
                    "override": null
                }
            ],
            "mentor": {
                "id": 91,
                "name": "Matthew Garcia",
                "email": "[Matthew_Garcia311@berkeley.edu](mailto:Matthew_Garcia311@berkeley.edu)",
                "section": 91
            },
            "capacity": 4,
            "associatedProfileId": 2,
            "numStudentsEnrolled": 4,
            "description": "",
            "course": "EECS16B",
            "userRole": "COORDINATOR",
            "courseTitle": "Designing Information Devices and Systems II",
            "courseRestricted": true
        }
    ],"students": [
        {
            "id": 224,
            "name": "Grant Hudson",
            "email": "[Grant_Hudson314@berkeley.edu](mailto:Grant_Hudson314@berkeley.edu)",
            "section": 91,
            "mentor": "Matthew Garcia",
            "numAbsences": 4
        }
    ]```
    

[smartspot2]

Overall, seems good for an initial implementation of a search query, with a few small comments. I'd forsee that you'll need to create a new custom serializer for this data though, since any expansions/modifications to the kinds of data we're querying over would be hard to do with this current implementation.

[smartspot2]

The model visualization files should be excluded from the commits (either move them outside of the repository folder, or delete them)

[smartspot2]

Generally, the path itself shouldn't need to include actions like "get"; the HTTP method that the request has should indicate what the user wants. The more conventional path would be something like search/sections/.

[smartspot2]

I'd recommend adding a little more detail in this docstring describing exactly what the view expects from the request (ex. all of the possible query parameters, possible values for each parameter, how it handles each parameter, etc.)

[smartspot2]

This students object seems to be overwritten in the if statements below when working with student_absences. If it's possible to provide both the query and the student_absences parameters, then they should work together properly. (And this should be explained in the docstring as well.)

[smartspot2]

It seems like you also accept ranges, so more than just integers should be expected (and the error message should reflect that).

An alternative to providing this union of possible types is to specify a new (mutually exclusive) query parameter for a range of student absences. Either works though, so it's up to you whether you want to stick with this or split it up.