discord-csharp
Per-Guild Configuration
I thought this already existed, but it seems it does not.
This issue is to contain discussions and notes on how to implement guild-specific configuration items. When a MODiX instance is a member of multiple guilds, these guilds may have different requirements, and so a system should be provided to allow for this.
That a system should exist is agreed upon by maintainers, however the methodology for implementing this system is still up for debate. Currently, there are two prevailing ideas:
- Persistent KeyValue pair storage, where the Key is the guild Id and the Value is a JSON-formatted string containing each of the configuration items.
- Benefits
- Easy to add and remove configuration items, simply by providing a default value for new changes and updating the JSON in the database.
- Detriments
- Doesn't scale well. As more values are added, processing time will slow.
- Data reads are slow, writes are fast.
- Benefits
- New table with a key column using the guild's Id, then a column for each configuration item.
- Benefits
- Fast reads and writes
- Moderate scalability
- Detriments
- Adding or removing configuration items requires a schema update; may be a breaking change.
- May be over-built for just a handful of configuration items.
- Benefits
My first thought is that any configuration options that don't need to be live-editable should be handled by the Microsoft.Extensions.Configuration system. We can simplify a LOT of effort on our part by not engineernig tables and UI's and whatnot for stuff that will rarely rarely ever need to change. A quick bot restart to deploy new config is not the end of the world. Also, Microsoft.Extensions.Configuration does support live editing, depending on the provider.
This can easily be applied for guild-specific configs as well, depending on how many guilds you need to support, by having sections in the config keyed by guild ID. It also depends on how often the bot is added to or removed from guilds.
For config that we DO want in the DB, I like the idea of not mixing features into one single table, at which point it's probably silly to make a key/value table over a schema-modeled table. Migrations don't scare me too much, so long as they're thoroughly thought through (how's that for a tongue twister).
Also, I think any configuration stored in the database should be backed by an Actions table, for the sake of logging, even we never make a direct UI for it. I know the implementation of ModerationActions and PromotionActions are a bit convoluted, so we don't have to implement new such tables in the exact same way. I actually have a similar setup in a personal project that I think works MUCH better. It doesn't require a whole bunch of weird custom EF relationships.
As part of a new effort to refocus on priorities, I will close this. If you feel this is imperative to the bot, a new issue can be opened to supersede this.
