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 and course_units_by_year what was being retrieved was all the CourseUnit objects that matched the parameters passed to the view and in the course_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 the course_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.
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_unitsandcourse_units_by_yearwhat was being retrieved was all the CourseUnit objects that matched the parameters passed to the view and in thecourse_last_yearwas 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_yearview 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_yearattribute and the result of thecourse_units apiwas 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.