Closed raven0034 closed 2 years ago
Should probably add some stuff for not storing keys in actions where the values are empty for the sake of saving some DB space (e.g. if you're just storing a key's value as an empty list there's no point storing it in the first place)
The starboard cog needs tweaking somewhat so there's not massive overhead every time there's a reaction with it requesting starboard entries. Also could do with some better way of tracking entries, specifically whether they need to be created or not, since spamming/lots of people reacting quickly can cause the bot to have a fit and create two messages. Some sort of queue or something similar may be ideal so it doesn't conflict.
Will pick up work again on this at some point in the near future. Want to transition to Python 3.10 and make proper use of some of the new features.
On windows: matplotlib 3.4 will not build on Python 3.10, but 3.5.0rc1 does appear to work
Next steps: decentralise the db schemas and config keys (not decided on whether to do this in separate tables or feed into the config table as now) - this is part of an effort to ensure changes made do not have an impact on cogs they aren't related to. Eventually a cog should be able to be "dropped" into the project and (obvs providing it conforms to certain protocol specific to Adam-Bot) work without having to modify unrelated files within the project itself.
For stuff like the GCSE server for example a repo could be created with cog(s) specific to that server without being part of the "main project" ie other people can make use of it without extra baggage.
Finally made it such that cogs largely have control over the config keys that they make use of - they are now stored within each cog's config file. Some keys that are key to the bot actually functioning have been retained in the old format (namely the staff role, logging and the prefix). This leads us closer to the "plug and play" style of cogs where they can simply be added to the downloaded instance of the bot, added to the config file and can be made use of without having to modify half of the project files in the process.
Given that config key creation is a lot more dynamic there is also now extra code to handle creating new columns on the spot although ONLY if there is data to be propagated for such a new column for any given guild (ie it will NOT create columns where all the data will just be null). With that said it may be worth looking at removing columns that have become all null for pre-existing columns, but this is of a lower priority.
Extending from this, as such config keys are only loaded on where the cog has been loaded in - although at some point I will look at clearing up phantom keys (ie keys that are loaded but then a cog fails to load (hopefully not an issue that will occur with the current cogs, but something that should be accounted for)
Just spotted "bruhs" are currently broken because it's not actually a config key
This is a step forward considering before you'd have to manually interact with each and every db you had one/more instances of the bot connected to add the new columns - instead now just add to the cog config and it gets handled upon redeployment. Ideally we could also do with validating the columns have been created as expected (ie with the correct type(s) and any constraints)
🙏 let's do it
What has changed:
Some new cogs have been added:
discord.py
Dependencies (update: 4/12/21)
Other somewhat notable changes
Is this everything?