We have updated the logic of the grading system, and the remaining part is to change submission selection logic. ATM, this is done in a scary raw sql query in CompareProposals module.
According to the new logic, selection of a design pair should go using Rating table as follows:
Selection of the least popular criterion: use sum(currentEvidenceW) grouped by criterionId
Order designs by their evidence levels (currentEvidenceW), randomize a little (see the existing query fo the hint)
Filter designs:
should not be authored by the voter
should belong to the same ScenarioProblemId (a.k.a. exericse_id, task_id, problem_id)
select pairs of designs among the ones with the least evidenceW
make sure this exact design pair never occurred to the voter (by using table Vote)
There is a chance that this query can now be implemented using esqueleto, because it should be drastically simplified. Most of the important information is available in two tables: Rating and CurrentScenario. But we still need to use Vote table to make sure the pair was not presented to the voter previously.
We have updated the logic of the grading system, and the remaining part is to change submission selection logic. ATM, this is done in a scary raw sql query in CompareProposals module. According to the new logic, selection of a design pair should go using
Ratingtable as follows:ScenarioProblemId(a.k.a. exericse_id, task_id, problem_id)Vote)There is a chance that this query can now be implemented using esqueleto, because it should be drastically simplified. Most of the important information is available in two tables: Rating and CurrentScenario. But we still need to use
Votetable to make sure the pair was not presented to the voter previously.