In the database manager especially, there are a lot of places where hardcoded values are used and have to be maintained across each individual module. This is not ideal as, as proven during development, it creates many situations where it's required to go back and look at the specific key name (notably an issue with the meta table, where this issue cannot be resolved as simply).
Will update this issue in the future with more ideas on how to fix it. For now, this issue will not be slated for any particular release, as I'd like to get it implemented as soon as possible but only after a plan is made.
My initial thought is to implement a dataclass that gets expanded when necessary, for instance, as more meta rows are added to the database. Right now there are several known rows in the database's meta table, round_end, update_round, cur_points, etc. that could be standardised into a constant string value instead of manually written as needed, which involves remembering the exact spelling and word order.
Of course, this isn't easily expandable, as we could add more values to it in the future, but what about more short-term meta rows? Short-term meta rows would still require in-line hardcoded values. A dynamic dataclass which allows adding and removing attributes to track this would not resolve the issue, as many IDEs would be unable to tell if/when the attributes are valid or invalid.
I'll continue to work on this over time, it's not the highest priority until the next database update. When the database gets upgraded, this will likely be made into a prerequisite.
In the database manager especially, there are a lot of places where hardcoded values are used and have to be maintained across each individual module. This is not ideal as, as proven during development, it creates many situations where it's required to go back and look at the specific key name (notably an issue with the meta table, where this issue cannot be resolved as simply).
Will update this issue in the future with more ideas on how to fix it. For now, this issue will not be slated for any particular release, as I'd like to get it implemented as soon as possible but only after a plan is made.
My initial thought is to implement a dataclass that gets expanded when necessary, for instance, as more meta rows are added to the database. Right now there are several known rows in the database's meta table,
round_end,update_round,cur_points, etc. that could be standardised into a constant string value instead of manually written as needed, which involves remembering the exact spelling and word order.Of course, this isn't easily expandable, as we could add more values to it in the future, but what about more short-term meta rows? Short-term meta rows would still require in-line hardcoded values. A dynamic dataclass which allows adding and removing attributes to track this would not resolve the issue, as many IDEs would be unable to tell if/when the attributes are valid or invalid.
I'll continue to work on this over time, it's not the highest priority until the next database update. When the database gets upgraded, this will likely be made into a prerequisite.