To compute the possible matches between students, this service was used.
A student, when requesting an exchange, can select the shift they would like to move to - the student cannot have a pending exchange request for that course.
When that choice is made, the full set of pending requests for that course is sent to the solver service. Whilst waiting for a response, those rows in the DB are locked as to prevent data races.
The solver returns the set of possible exchanges (which can involve multiple students). Swap then proceeds to change the students' enrollments accordingly, and removing the pending exchanges from the DB.
The only modification to the data model that was made was allowing enrollments to have a null student id. If an exchange is to an enrollment which has a null student, it is treated as an automatic exchange. The same applies for the logging table.
I would like to thank everyone (@lumafepe, @raddrax, @nelsonmestevao) who contributed to this improvement 🙏
Closes #12 .
To compute the possible matches between students, this service was used.
A student, when requesting an exchange, can select the shift they would like to move to - the student cannot have a pending exchange request for that course.
When that choice is made, the full set of pending requests for that course is sent to the solver service. Whilst waiting for a response, those rows in the DB are locked as to prevent data races.
The solver returns the set of possible exchanges (which can involve multiple students). Swap then proceeds to change the students' enrollments accordingly, and removing the pending exchanges from the DB.
The only modification to the data model that was made was allowing enrollments to have a null student id. If an exchange is to an enrollment which has a null student, it is treated as an automatic exchange. The same applies for the logging table.
I would like to thank everyone (@lumafepe, @raddrax, @nelsonmestevao) who contributed to this improvement 🙏