Drop computable Rankings.percentage and provide func #193
Conversation
At model instance .save() time, we were calculating the value of one column using two others. Since the type of that column is an IntegerField but elsewhere on the site we round to one digit after decimal, a reader complained about the inconsistency (really that it was a floor() operation). Instead, this is the first part of the whole fix, but someone else can "makemigrations" to discard the db column at leisure. Closes ebmdatalab#184
|
I didn't actually test this. Sorry. |
|
Thanks for the PR! However, Now, I'm not sure anyone cares about sorting or filtering by percentage in the API, so perhaps this is an opportunity to excise unused code - in our frontend we sort in javascript, and anyone else can sort how they want once they've downloaded. However, if we did that, we should change how rankings are computed as @NickCEBM has said previously he's going to find historic rankings useful for future analyses - right Nick? All in all, I think there's an argument here (given we don't actually know if/how others are using the API, and the extra work) for continuing to set the value as a database field, but matching how we round it elsewhere. |
|
Yes, historic rankings are a very nice thing to have for a number of reasons. |
At model instance .save() time, we were calculating the value of one column
using two others.
Since the type of that column is an IntegerField but elsewhere on the site we
round to one digit after decimal, a reader complained about the inconsistency
(really that it was a floor() operation).
Instead, this is the first part of the whole fix, but someone else can
"makemigrations" to discard the db column at leisure.
Closes #184