This follows from investigations in
https://rt.lca2018.org/Ticket/Display.html?id=283&results=eac0bd3c49f782d054f87d6b160ca36b;
in short, it seems that because this very long and complex method
creates several different objects at differnt times, the DB has been
getting out of sync; there are more votes recorded then there are
reviews, becuase the table that stores the vote count is updated
before the table that stores the vote and review information
This change is intended to make this operation (and the other
operations that the revew_detail handler performs) atomic, to prevent
things getting further out of step. It does *not* fix the existing
incosistency.
review_delete has been atomicified as well as it likely needs the same
treatment, but this has not been examined in detail.
Resolves:
File "/app/symposion_app/vendor/symposion/reviews/views.py", line 230, in review_random_proposal
proposals = proposals[:(len(proposals) + 1) / 2]
TypeError: slice indices must be integers or None or have an __index__ method
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.
