Currently a global postgres connection is assigned at the top of the bot file, and then functions inside the event_handlers in the bot.py pass the connection in to dbhelpers.py functions. To better decouple this logic a custom connection object should be managed which provides an interface to pass around generic connections/ connection pools.
Additionally there is some some off sql logic in bot.py that should be moved entirely into dbhelpers.py.
Also dbhelpers.py should be renamed to something that makes it clear that postgres is the "db".
Perhaps I should define global interfaces for the business logic which would pave the way for adding support for other databases. Perhaps a plugin system to manage which database is configured?
Additionally I've had to fight bugs such as trying to use a chat_id for a chat that doesnt exist, and thus insert updating the telegram chat any time before it's needed in case it didn't exist previously. A layer of abstraction could help this be less troublesome and cause less code duplication (perhaps annotations like "@uses_chat" could make the db calls underneath)
Currently a global postgres connection is assigned at the top of the bot file, and then functions inside the event_handlers in the bot.py pass the connection in to dbhelpers.py functions. To better decouple this logic a custom connection object should be managed which provides an interface to pass around generic connections/ connection pools. Additionally there is some some off sql logic in bot.py that should be moved entirely into dbhelpers.py. Also dbhelpers.py should be renamed to something that makes it clear that postgres is the "db". Perhaps I should define global interfaces for the business logic which would pave the way for adding support for other databases. Perhaps a plugin system to manage which database is configured?
Additionally I've had to fight bugs such as trying to use a chat_id for a chat that doesnt exist, and thus insert updating the telegram chat any time before it's needed in case it didn't exist previously. A layer of abstraction could help this be less troublesome and cause less code duplication (perhaps annotations like "@uses_chat" could make the db calls underneath)
Especially problem child methods: