What's the point of subtype?
It is not necessary. It is just my point of view. The same solution can be done to type only. But then "type" will be one of ["Glicko official weekly", "Glicko official instant", "Glicko all weekly", "Glicko all instant", ...]. With type and subtype you has less types. But it is not necessary at all.
- What's the point of having such function in the model? Never seen that
save() is called every time when object of the model is created or updated in the database. In my code I have overridden the original function by small piece. At the end you can see two lines:
super().save() # for Python 3.X and
super(Rating, self).save() # for Python 2.7 which are one for each version of Python (I don't know which is used now in Widelands). Those lines are calling original
save function from
Why in my proposal is such thing? Because that is solving updating
active value to
False when new record appear. So that no other action is needed, but the history of the records is preserved.
- Isn't the server always in python3?
I am not sure what do you mean by "server". "Save" function exists in all django classes that are inheriting from
Why not put everything in floats? If we are gonna use many score system, just transform to int when retrieving from db. 2 less lines
You're right. Since we won't reach 10^15 cases, the float and integer values will be the same. But as it was suggested by WorldSavior, I have forgot about forfeits in my "simplest rank", so it needs 3 values instead of 2.
updated = models.DateTimeField(auto_now_add=True)
active = models.BooleanField(default=True)
Couldn't we rather have a new table with a season data (start date, end date, selected maps, players that particpated, their games, all the scores)? ==> i.e all that will be shown on the website to players
It would also avoid this idea of active and inactive.
I am not sure what do you mean by "season data", or rather: how it will be stored? But as I understand, you want to store old data in an "archive table". It is possible to do that. For very large tables (millions of records) it is even better, but as I understand our situation (up to 100 records per week) it will be enough to store everything in one table. I know that the model I propose seem to be a bit more complicated, but it is not the worst one . Of course you don't have to implement such system. You can do anything you think is a good idea. It is possible to implement without history of records, and the "active" should be erased from the model.
Hopefully I answered all you questions for now.