parrot
parrot copied to clipboard
aquelemiguel
Serialize/Deserialize `GuildSettings` for persistency
Rationale
We should have persistent-based settings (for example for the default Parrot language for that guild). These settings need to be persisted and read at the start.
Description
Serialize and deserialize the current GuildSettings struct. Attributes that should be persisted should be settings, others should be guild cache.
This should be done in a more generic way so that any new setting added does not change the persistency code and we don't need to maintain JSON files and know their structures (likely use serde).
Reference
- https://crates.io/crates/serde_json
- https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4cfb0ce22e910da4e432cb5a2e6f0aab
@afonsojramos @aquelemiguel adding a triage label. If we all approve the issue, we consider it and remove the triage label. I would want to take this one.
It's easy to imagine when the deserialization will happen, but when would the serialization happen?
That's a great point that I did not think through. I have no idea right now, I will think about it and get back to this.
This was exactly my problem when I was developing #69.
Maybe the merge_json function could be re-added for this to work.
pub fn merge_json(a: &mut Value, b: &Value) {
match (a, b) {
(&mut Value::Object(ref mut a), &Value::Object(ref b)) => {
for (k, v) in b {
merge_json(a.entry(k.clone()).or_insert(Value::Null), v);
}
}
(a, b) => {
*a = b.clone();
}
}
}
The function helps in merging JSONs, not so much the problem at hand which is WHEN to in fact save/serialize the settings.
It could end up being done in the same way as before when a setting changes. But I will look better into it. We can also just use eventual consistency as these settings are not that critical.
It does because you can use it every time you update the settings, that was my point. You can observe that it is what is happening in #69.
What do you mean by "eventual consistency"?
Again, it is not related. I know how to merge JSONs, and eventually, I would use that function. The problem/issue remains of WHEN to merge and save it (should it be done every time a setting is updated, like we have done in #69 ? Maybe yes, maybe not, all I am saying is that this is the issue at hand).
What do you mean by "eventual consistency"?
I meant, routinely saving the settings, periodic handler fashion. This would not guarantee that the latest settings would be saved if parrot crashed, but might work.
Again, I am just spit-balling, I haven't thought much of it yet and I have no time right now.
Haven't implemented anything, but I think the serialization should be:
- done for the struct entirely (read and write whole settings)
- done when we change some setting (altering prefix for example)
altering prefix for example
This does not happen anymore, but I get what you are saying. If you are out of time let me know and maybe I can give it a try :eyes:
It is fine. I will do it.
I think there is no alternative to saving whenever a setting changes. I will abstract this into its module and function(s) but the person updating the setting must remember to update the serialized version.
As for serialization/deserialization, it should be pretty simple using serde.
The only problem right now is I think we don't have settings worth serializing. So I will work with the autopause one for now, but this should be removed and sent to the cache in the future.