search

SinisterRectus / Discordia

Discord API library written in Lua for the Luvit runtime environment
MIT License
712 stars 145 forks source link

Discordia's caching model #142

Open Mehgugs opened 6 years ago

Mehgugs commented 6 years ago

Currently discordia objects store there children in an instance of the Cache class (or it's derivatives) however the Cache class is used as a container for an object's children and a object cache simultaneously.

The issue with a hybrid model like this is that there has to be a trade off between retaining state so that events can have good context (messageDelete being aware of the message's properties for example.) and also reflecting changes from HTTP requests et al. instantly. (The count of channel.messages should always decrement when you delete one of it's messages.)

My suggestion is that discordia separates these two concerns into different objects; so that the logic for both remains simple. (Trying to handle the edge cases in one object is a problem.)

Add a new Collection class which discordia objects use to store their children, calling methods on this class to change it's contents happen synchronously so it doesn't need to try and keep hold of objects.

Change the Cache class to be a cache of full objects which should keep objects until they are known to be removed. This class would only be focused on storing objects not on reflecting events immediately.

SinisterRectus commented 6 years ago

This will almost certainly not change until the next major version of Discordia.

SinisterRectus commented 5 years ago

This has been addressed in commit 4eefacad005903f6768654f0fbd53da9a7535e0f. I'll keep this idea in mind, but I'd like to stick with a simpler solution moving forward rather than introduce more classes. I think that the next step for improving message caching would be that which is outlined in #214.

SinisterRectus commented 5 years ago

Decided to re-open this because the idea here is good. Not yet sure if it will be implemented though.

SinisterRectus commented 3 years ago

Caching has been overhauled for 3.0. Caches and cached objects are now hidden internally in a central client state manager. If the client requests permanently cached objects, for example, a guild's roles, the client collects the objects from the internal cache and returns references to them in a newly constructed static iterable. The occurrence of objects in that iterable does not change (unless the user manipulates the iterable). For example, if a role is deleted on Discord's server, it will be removed from the client's internal cache, but the role will still exist in the static iterable as long as the user holds onto it. The objects themselves may change as updates are received for them, since they are references to the same objects stored and manipulated in cache.