Refactor: course_units_api now searches courses and course_units through course_unit_year table #53
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #51
Note: Currently, as the new modifications to the tables and the scrapper are not on the develop branch yet, when you are testing this, it is most likely that the course_unit_year table is empty on the local version of your database and that is probably the reason why if you run this backend version it will not work correctly as it will return an empty array if you're course_unit_year table is also empty.
Why was this necessary
For future reference
In order to address the planned changes in the database, it was necessary to now retrieve information about course units through the course_unit_year table as the same course unit can have more than one curricular year, instead of risking having more than one entry in the database about the same course unit where the only thing different would be the curricular year, which would happen with the old schema.
How was it done
Previously, in the django views
course_units
andcourse_units_by_year
what was being retrieved was all the CourseUnit objects that matched the parameters passed to the view and in thecourse_last_year
was searching through the course_units table.The changes were
Instead of using the CourseUnit model, the model used is now the CourseMetadata
It now concatenates the dictionary of a certain course unit metadata instance and the dictionary of a the course unit
whose id is the same as in the course unit metadata
In the
course_last_year
view now it searches the max course_year going through the course_unit_year table and not through the course_unit one.How was it tested
This was tested by creating two entries in the course_unit_year table that linked to the same course and course_unit but had different values for the
course_year
attribute and the result of thecourse_units api
was correct.Note: In reality, this course unit does not have multiple years. It's just that way in this case because it was an hardcoded example.