Sentinel History Rewrite

cswimr commented

2026-02-20 12:00:34 -05:00

Owner

This pull request completely rewrites Sentinel's history method, pulling it out of SentinelCog and into its own views.history module. Closes #78.

The new API can be accessed at tidegear.sentinel.HistoryView.

This also includes changes to Tidegear's emoji system, but they're internal and shouldn't qualify as a breaking change (only private attributes / methods were changed in an incompatible way).

The new history system works as such:

Consumer calls HistoryView.send() with their filters.
That method constructs a _HistoryOpts object, which ties into SentinelCog methods to actually fetch moderations.
Two Piccolo queries are made at this point. One to fetch the first <pagesize> moderations that satisfy the given filters, and one to count the number of rows that satisfy the given filters. This COUNT query is not repeated again in normal usage.
A couple fields on the _HistoryOpts object are hydrated with the query results. This is then used to compute the total number of pages for the given <pagesize>.
An embed is constructed with information on each of the fetched moderations.
Buttons are constructed and added to the view, accordingly with the number of available pages. If there are more total moderations than were retrieved accordingly to <pagesize>, pagination buttons will be available.
- Different pagination buttons have different operational methods. Next/Back use keyset pagination, whereas First/Last/Jump to Page use offset pagination. Next/Back will be much faster as databases grow in row count, but for realistic usage, offset pagination is probably fine, and it'd be prohibitively difficult to implement keyset pagination for those other buttons.
Embed and view gets sent to user.

Not including message sending, the new system is about 412x or 99.76% faster than the legacy history method.

Old:

[red.tidegear.TidegearExampleCog.sentinel] History query completed in 38,144.360 ms with 14,483 moderations retrieved! Query construction time: '18.967 ms' Query time: '10,581.014 ms' Moderation iteration time: '27,544.379 ms' Longest moderation iteration: 'Moderation 7,128 with 6.017 ms' Avg. time per moderation: '1.902 ms'

New:

[red.tidegear.TidegearExampleCog.sentinel] History menu creation completed in 0.689468 seconds with 12 moderations retrieved. Query time: '87.049682 milliseconds' Moderation iteration time: '5.440367 milliseconds' Longest moderation interaction: 'Moderation 14483 with 0.851507 milliseconds' Avg. time per moderation: '0.453364 milliseconds' Message send time: '342.008403 milliseconds'

This pull request completely rewrites Sentinel's history method, pulling it out of `SentinelCog` and into its own `views.history` module. Closes #78. The new API can be accessed at `tidegear.sentinel.HistoryView`. This also includes changes to Tidegear's emoji system, but they're internal and shouldn't qualify as a breaking change (only private attributes / methods were changed in an incompatible way). The new history system works as such: - Consumer calls `HistoryView.send()` with their filters. - That method constructs a `_HistoryOpts` object, which ties into `SentinelCog` methods to actually fetch moderations. - Two Piccolo queries are made at this point. One to fetch the first `<pagesize>` moderations that satisfy the given filters, and one to count the number of rows that satisfy the given filters. **This `COUNT` query is not repeated again in normal usage.** - A couple fields on the `_HistoryOpts` object are hydrated with the query results. This is then used to compute the total number of pages for the given `<pagesize>`. - An embed is constructed with information on each of the fetched moderations. - Buttons are constructed and added to the view, accordingly with the number of available pages. If there are more total moderations than were retrieved accordingly to `<pagesize>`, pagination buttons will be available. - Different pagination buttons have different operational methods. `Next`/`Back` use keyset pagination, whereas `First`/`Last`/`Jump to Page` use offset pagination. `Next`/`Back` will be much faster as databases grow in row count, but for realistic usage, offset pagination is probably fine, and it'd be prohibitively difficult to implement keyset pagination for those other buttons. - Embed and view gets sent to user. Not including message sending, the new system is about **412x or 99.76% faster** than the legacy history method. Old: ``` [red.tidegear.TidegearExampleCog.sentinel] History query completed in 38,144.360 ms with 14,483 moderations retrieved! Query construction time: '18.967 ms' Query time: '10,581.014 ms' Moderation iteration time: '27,544.379 ms' Longest moderation iteration: 'Moderation 7,128 with 6.017 ms' Avg. time per moderation: '1.902 ms' ``` New: ``` [red.tidegear.TidegearExampleCog.sentinel] History menu creation completed in 0.689468 seconds with 12 moderations retrieved. Query time: '87.049682 milliseconds' Moderation iteration time: '5.440367 milliseconds' Longest moderation interaction: 'Moderation 14483 with 0.851507 milliseconds' Avg. time per moderation: '0.453364 milliseconds' Message send time: '342.008403 milliseconds' ```