I have no idea why we do this in the database as some magic after we
call save(). I also have no idea why MySQL is seeming to think we want
type BIGINT UNSIGNED at the end of the
((2 * '+2' + '+1') - ( '-1' + 2 * '-2')) but it does.
Setting it to 2.0 or float(2) doesn't get the ORM to get this right, but
we are going to Decimal and making the 2 multiplier be of type Decimal
manages to make the ORM pull it's shit together and use something that
seems like we're okay with.
+1, -2 = 1 / 2 = -0.5 Score == True
Looks like it works.
UPDATE `symposion_reviews_proposalresult` SET `score` = CASE WHEN `symposion_reviews_proposalresult`.`vote_count` = 0 THEN '0' ELSE ((((2 * `symposion_reviews_proposalresult`.`plus_two`) + `symposion_reviews_proposalresult`.`plus_one`) - (`symposion_reviews_proposalresult`.`minus_one` + (2 * `symposion_reviews_proposalresult`.`minus_two`))) / (`symposion_reviews_proposalresult`.`vote_count` * 1)) END WHERE `symposion_reviews_proposalresult`.`id` = 1
The current ordering is based on what appears to be a random ordering
that happens to correlate to the last time the paper was submitted or
updated. Oldest to most recent.
This changes it to submission order so ordering doesn't change and ID is
a static, making it easier to move through a list of papers. "I last
looked at 24, so 25 is assured to be the next one I want to look at.
There's the thought of updated papers being looked at and voted on, but
it does not seem to me that this is supported or possible. In general
one would look at their un-reviewed list, and go off it, which puts
updates out the window.
We can certainly order on other fields if desired, but this one makes
the most since to me.
This was removed somewhere in 1.8, which means this results in a
failure. If I understand correctly, this "name" is now derived from the
model name's __str__ or something like that.
