Key-Value-based Backend

[TurnrDev]

This is a backend rewrite to support more flexibility with growth and customizability. This is loosely based on how OpenStreetMap operates.

Currently, we have one model (Update) representing a statistics update. This holds some metadata such as when the update was created, last modified and what software was used to last modify it, alongside hard-coded fields for every stat. This causes several issues, included database migrations every time a new stat is released. Querying a profile to find out the latest of each stat is difficult and impossible to know for sure when each stat was actually posted. This system has no support for custom stats, and prevents people from adding new stats until the developer updater the models.

The new system proposes two models:

• The Post model, which is similar to the changeset model on OpenStreetMap. It will hold metadata such as where data was submitted from (discord message id, bot id, user id etc), which player it relates to, when the post was created, and when the post was closed to edits etc
• The Tag model, which is similar to the changeset_tag model in OpenStreetMap. It will hold a single key-value pair, a foreign key link to the player, a foreign key link to the Post, a creation datetime, a state value

Once a Tag has been made, it can't be edited.
A Post can only have one Tag per Tag.key assigned to it (no total_xp assigned twice)

The previous Update model should be able to be converted into the new system fairly flawlessly.

Tag objects can be practically identical to previous Tag objects (except time+post) but can never decrease.
If the parsed value on a Tag object is deemed to be invalid (smaller than, grew too large too quickly), its state will change from PENDING to NEEDS_REVIEW. The states are;

PENDING: The value hasn't been parsed by the validation engine yet.
OKAY: The value has been parsed by the validation engine, and everything looks fine.
INVALID: The value has been parsed by the validation engine, but it could not cast the value to the expected type.
CUSTOM: The value was ignored by the validation engine and left as-is.
NEEDS_REVIEW: The value has been parsed by the validation engine, but it did not look right and needs human review.
REJECTED: The value has been parsed by the validation engine, but it did not look right and was rejected by a human.
ACCEPTED: The value has been parsed by the validation engine, but it did not look right but was accepted by a human.
FIXED: The value has been parsed by the validation engine, but it did not look right but was accepted and changed by a human.

This new system will allow custom stats whilst still allowing the supported stats to be validated.

[TurnrDev]

The project for this is here.