-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Closed
Description
Is your feature request related to a problem? Please describe.
- The
CallbackContextintroduced in v12 is a very central thing in the library and at some point people will wanna customize it, especially when usingcollect_additional_contextin custom handlers. Also when we get typing (Type hinting #1920, due to v13), type checkers will complain setting custom attributes. - The persistence setup, which is tightly integrated with
context, has two shortcomings:- Currently, on startup all data is loaded from the persistence-backend, which might slow down the startup on huge databases and even might be unneccessary. Allowing to implement a fetch-on-demand logic would solve that
- When sharing a database with an external service, currently there is no automated way to update the data while running the process. Again, more customization of the persistence setup could solve that
Describe the solution you'd like
- Allow for
BasePersistence.get_data()to return custom classes, defaulting todict(). That way users can solve both of the above mentioned problems on their own (same forget_conversations). For most classes this should still be compatible with the changes introduced in Refactor Bot persistence #1994, but advanced users can useset/replace_bot()manually anyway … - Allow to pass a custom subclass of
CallbackContexttoUpdater/Dispatcherthat will be used instead ofCallbackContext. We should documentCC.from_*()for that. - Those custom classes (3 for
bot/user/chat_data, 1 forcontext) should be passable toUpdater/Dispatcherin a clean way. I.e. probably add a single parameter to pass it as tuple/dict/custom class or maybe add it to theDefaultsclass, although I'm not sure that's a good idea - As we're introducing type hinting in v13 (Type hinting #1920), ideally the typing is clever enough to tell the handlers that they get
(update: Update, context: CustomCallbackContext)instead of(update: Update, context: CallbackContext)
Describe alternatives you've considered
Additional context
Reference for devs: @JosXa @tsnoam and I had a brief discussion about some of these ideas in dev chat on 2020-08-25.
Metadata
Metadata
Assignees
Labels
No labels