This allows easier database migration, no code changes need to be done when migrating, one can just run the migrate command, or possible one of the others.

Currently migration happens, if something goes wrong, the user has to manually add code to the bot, that clears the DB or something alike. This is horrible developer experience

Motivation

Currently, the user manually has to create a lot of dashboards/panels. This is a very time-consuming task, and especially when you want metrics with more labels, this is going to take a lot of time. By generating these panels on creation, no manual work will need to be done, improving UX drastically.

Implementation

Creation of limited simple Grafana api wrapper, where all calls are blocking to make it really simplistic. Using jackson automatic JSON serialization/deserliazation.

Info

See the documentation of the Grafana API

See #1

Motivation

Statistics are fun and interesting, an undeniable fact.

Implementation

Unlike #1, this is there to implement statistics about specific commands. How long a specific command takes to run, and how often it gets run. To implement this, I need commands to know how I'll exactly implement this. Therefor it's blocked till commands have been added.

Info

See the Java client, or their website

Prometheus is software for displaying metrics on your application.

Motivation

Statistics are fun and interesting, an undeniable fact.

Implementation

For now, implement statistics in general. Things like ram usage, how often commands get ran and such. This also includes how long the checks before the command take, and how often interactions run. This isn't yet command specific, but globally.

Command specific statistics

This is for statistics for how often each indivual command gets run, and how long they indiviually take. See #2 for more info

Info

See the Java client, or their website

Adding an insert that inserts or replaces is kinda sketchy since the name suggests otherwise. Adding a dedicated replace method makes it clear what actually happens, and causes behaviour to be equal and expected over the different implementations.

Reworks the before-hand really trashy DB system.

After this rework it's been improved a lot, but still isn't optimal.

This rework adds an universal interface (IDatabase and IStringDatabase) which adds common methods.

And this rework also adds AbstractDatabase which works against duplicated code, and bloated code by adding helper methods.

From now on, Database will also have all the other Databases, they shouldn't (and can't) be made anymore using their constructor.

While this by far isn't enough, tests are a long lasting process, they'll be added over time. And for new PR's and commits, a quick look will be made to check or "test" are realistic, if yes, they will be added in that (or the following) commit.

Closes #23

This PR implements DiscordClientAction which adds easier support for running "actions" / opening "pages" within the Discord client.

See https://github.com/Together-Java/TJ-Bot/pull/391 for more info

Currently nothing is being tested by unit or integration tests, this means that errors may constantly happen when changes are being made to the system.

Tests would be beneficial to maintain quality, so 🔜

Currently a log of things aren't logged, we need to implement a logging (logback?) to show the information. This also allows us to set a custom pattern for better logging

User profiles

This aims to add:

The ability to create & edit your own user profile.

This functions using:

Modals & buttons, exact design is uncertain as of right now

The command's signature:

/profile [view/edit] (....)

or

Profile design:

Personal info is a custom field

Socials will be a non-custom field

Currently, in the code columnIndex is mainly being used.

This is fine, but the moment an column gets added, it has to be added to the end. This isn't always nice, and can cause weird tables.

Instead, columnLabel's should be used, that way the order doesn't matter and it can stay a logical order after updates.

This change only applies to ResultSet's, PreparedStatement's don't offer the functionality to use labels.

Currently the datasource get's created at all times, this isn't required. If it already exists, not creating it would most likely be more effective and less error-prone.

Some classes and methods have been added, which don't have documentation. While it's fine, nothing is wrong with adding documentation to possibly improve experience when maintaing in the far-fetched future.