I'll make this a draft PR for now. Dynamically modifying the fields isn't really a problem. There is an example in the Django Rest Framework documentation that I adapted for this. The problem is figuring out what type of round we have. In the code, this is the is_sprint_format function. I currently don't see a way of determining the weekend format at the round level without making additional database queries to check what kind of sessions there are. This results in around 20 additional queries, one for each race weekend, and this also causes some test failures because of the high number of queries.
One option would be to add the round type as a field to the round itself in the database and compute it when the data is imported. This is of course at the cost of duplicating information.
To do
[x] make this robust against individual sessions being cancelled / figure out if this could even be a problem
Contributing Checklist
[x] Unit tests for the changes are included in this PR.
Why are you making this change?
Fix #47
Notes
I'll make this a draft PR for now. Dynamically modifying the fields isn't really a problem. There is an example in the Django Rest Framework documentation that I adapted for this. The problem is figuring out what type of round we have. In the code, this is the
is_sprint_formatfunction. I currently don't see a way of determining the weekend format at the round level without making additional database queries to check what kind of sessions there are. This results in around 20 additional queries, one for each race weekend, and this also causes some test failures because of the high number of queries.One option would be to add the round type as a field to the round itself in the database and compute it when the data is imported. This is of course at the cost of duplicating information.
To do
Contributing Checklist