worldcubeassociation.org
worldcubeassociation.org copied to clipboard
thewca
Remove illegal cutoff formats
Very simple fix. These cutoff formats are not legal anymore, so they need to be removed. Please let me know if there's somewhere else in the code where this might need to be fixed. Afaik, it's just the model that needed to be updated.
So it seems like the fix is more complex than I thought, as some events that use Mo3 as the main format (FMC) may allow Bo2 cutoff format and some events that use Bo3 as the main format (MBLD) may also allow Bo2 cutoff format, so this should be treated on a case-by-case basis in the db. Due to this I believe we should add a proper field in the db for our events, where each event has a list of accepted cutoff formats, which would be cleaner than having a list of accepted formats in the model script. Please confirm that this is a good way to do it or provide an alternative in case there's a better method.
I'm not sure I follow your explanation in terms of there being an actual problem here.
some events that use Mo3 as the main format (FMC) may allow Bo2 cutoff format
--> Mo3 format corresponds to m format ID, so just set "m" => ["1", "2"]
some events that use Bo3 as the main format (MBLD) may also allow Bo2 cutoff format
--> Bo3 format corresponds to 3 format ID, so set "3" => ["1", "2"].
Can you please elaborate what's wrong with that approach?
--> Mo3 format corresponds to m format ID, so just set "m" => ["1", "2"]
6x6 and 7x7 are also Mo3, but having a cutoff phase of best of 2 is not allowed in those events. (But arguably, this can open up for the thought of why the Bo2 cutoff is allowed in FM since people who DNF the first attempt will anyway not get a mean. Though right now we need to deal with what is the current regulations)
--> Bo3 format corresponds to 3 format ID, so set "3" => ["1", "2"]
3/4/5-bld cannot have a cutoff, but I think this has treated separately in #6565 already. If so, this would solve the issue of MBLD.
Whew, this is becoming much less trivial than I had hoped. Indeed it seems like as per Daniel's remarks we have to change the entire codebase to determine allowed "first phase" formats per individual event and not per the general round format itself.
- Look for usages of
allowed_first_phase_formatsandallowedFirstPhaseFormatsin the code. Estimate how complex it would be to change those occurences from format-based to event-based (i.e. in the places in our code where this feature is currently being used, do we even have event data available?) - Check if this has implications on the WCIF spec over at thewca/wcif
- Tell me if I missed something yet again :stuck_out_tongue:
Just fyi, my schedule has freed up now and I will continue working on this PR. I'll try to implement a new db table column that specifies legal cutoff formats and try to incorporate that everywhere cutoff formats are used on the website and make sure nothing breaks as a result.
Since a bunch of ideas have been thrown around, I'd like to summarize what we need to do in one comment. Please confirm that this is the correct list of valid cutoff formats: 333: [2] (best of 2) 444: [2] 555: [2] 666: [1] 777: [1] 333bf: [1] 333fm (mo3): [1, 2] 333fm (bo2): [1] 333oh: [2] clock: [2] minx: [2] pyram: [2] skewb: [2] sq1: [2] 444bf: [1] 555bf: [1] 333mbf (bo2): [1] 333mbf (bo3): [1, 2]
Basically, we just need to have 1 -> [], 2 -> [1], 3 -> [1], m -> [1], a -> [2] with special cases for 333fm mo3, which has [1, 2] and 333mbf bo3, which has [1, 2]. I also reckon that we should only have a dropdown menu for cutoff only for these two special cases in the frontend, as no other round types would give you any choice, so there's no point in a dropdown.
Honestly, this whole issue is making me wonder why the WRC doesn't just make a specific cutoff format for fmc mo3 and mbld bo3, which should obviously be bo1
Honestly, this whole issue is making me wonder why the WRC doesn't just make a specific cutoff format for fmc mo3 and mbld bo3, which should obviously be bo1
Ask them! They are probably also the most qualified to approve/confirm your list of per-event cutoffs in the previous comment. Just shoot them a mail and don't forget to keep WST in CC.
For the record, we have internally discussed what to do with this issue exactly and have decided to go ahead with adding new data to our database that will specify a list of possible cutoff formats for each event + round type combination. I think the best way to do this is to have a new table that has an entry for every event which then have values for every round type that event could use. Of course, only a few events allow more than one main round type, but this way our code would be more flexible for the future. Here's an example of what I mean:
| Event | ao5 | mo3 | bo3 | bo2 | bo1 |
|---|---|---|---|---|---|
| 333 | 2 | null | null | null | null |
| 222 | 2 | null | null | null | null |
| 333bf | null | null | 1 | null | null |
| 333fm | null | 1,2 | null | 1 | null |
| 333mbf | null | null | 1,2 | 1 | null |
Please let me know if there's a more elegant way of doing this that I'm not seeing here. I could probably just use the same method from the model I edited in this very PR except add specific exceptions, but that would be less elegant and less flexible, although much easier. However, if the WRC ever made it so that there are no exceptions, the proposed table would become completely redundant, as there'd be just one filled in column for every entry.
The table structure you suggested is not flexible towards format changes. It also contains redundant information (i.e. all of the null columns). I would prefer something along the lines of
| Event | format | cutoff |
|---|---|---|
| 333 | a | 2 |
| 222 | a | 2 |
| 333bf | m | 1 |
| 333fm | m | 1 |
| 333fm | m | 2 |
| 333mbf | 3 | 2 |
| 333mbf | 3 | 1 |
| 333mbf | 2 | 1 |
You would then essentially select by event ID and actual format ID, and the result would be (potentially arbitrarily many) allowed cutoff formats. In cases where there's only one legal cutoff format, the returned list would only contain one element.
This table structure also makes it easier to add or remove cutoff formats without worrying about the table structure itself too much.
That is SO much better, thank you for the suggestion. I will get on this as soon as I'm done with my other PR.