This is a PR that includes a bunch of changes to get thread events working.
I've added Alembic for performing database migrations:
Migrations will run on bot startup during sql init, using the connection string from config.yaml
This is kind of hacky IMO, but it's convenient to avoid running CLI commands
If we don't want to do this, the connection string should be set in alembic.ini and commands like alembic stamp initial_revision_discord_py_1_5 and alembic upgrade head should be run before deployment
In the initial revision that describes the current state of the database, I've assumed discord.py v1.5, but upgrades to v1.7 are fairly minor, so there shouldn't be any issues
To accommodate threads, the messages and typing tables now have nullable channel_id, with extra nullable column thread_id. Either channel_id or thread_id should be populated
Some minor issues that aren't covered in this PR (they can probably be solved in future PRs):
Thread update events are mostly captured, except in the scenario where a thread is first archived, then deleted. In this scenario, the deletion event will not be captured by the client (we probably have to use discord.py's on_thread_remove? unsure.)
thread_member join events are captured, but leave events are not
Thread mentions (links) aren't captured in the mentions table
Unfortunately, none of the servers I moderate have a ton of thread activity, so I have only done some brief testing. I used python 3.9.9 (discord.py now requires a version greater than 3.7) and postgres 9.6. Migrations were tested by upgrading schemas created from the master branch with discord.py v1.5. I did not run pylint -- the pylintrc is a smidge out of date, I think.
This is a PR that includes a bunch of changes to get thread events working.
I've added Alembic for performing database migrations:
config.yamlalembic.iniand commands likealembic stamp initial_revision_discord_py_1_5andalembic upgrade headshould be run before deploymentmessagesandtypingtables now have nullablechannel_id, with extra nullable columnthread_id. Eitherchannel_idorthread_idshould be populatedSome minor issues that aren't covered in this PR (they can probably be solved in future PRs):
on_thread_remove? unsure.)thread_memberjoin events are captured, but leave events are notmentionstableUnfortunately, none of the servers I moderate have a ton of thread activity, so I have only done some brief testing. I used python 3.9.9 (discord.py now requires a version greater than 3.7) and postgres 9.6. Migrations were tested by upgrading schemas created from the master branch with discord.py v1.5. I did not run pylint -- the
pylintrcis a smidge out of date, I think.