Closed Skelmis closed 3 years ago
Another comment on 1
We should add the option for how long User
objects should be persisted. They should be persisted so punishments carry over between kicks, however, if they get banned it can be assumed we can wipe their data. Don't think ill force the ban wipe, however, definitely having some form of logging to maintain whether or not a User
can be cleaned up would be nice.
Programmatic view for if a User
can be wiped:
Message
's
x
as a general rule should be somewhat high, to avoid cleaning up User
's who have got outstanding warns/kicks
This cleanup will also only be a manual call, for those who want to cleanup things. It will not be forced at this time unless performance comes to the forefront as an issueProgrammatic view for if a Guild
can be wiped:
User
'sI think thats it?
The above should be profiled to see if its actually making a difference or not however..
Closing for now
I'm looking to create a list here of things that currently 'exist' but definitely have better ways of doing things which could lead to a noticable increase in speeds
Given the nature of threading and locks within the library currently and how poorly they have faired in the past, I might look to outsource this as a public method which the user has the option to call themselves until future notice.
An ideal solution would not create any objects and be under O(n), currently however I am considering abstracting away all current storage objects into abc classes which merely have the dunder methods and the data required for them. This would allow for somewhat lighter weight comparisons and also might help to cleanup the classes in the library a bit
These are the only couple off my head now, however I would appreciate anything other developers have to contribute.