Storage
SQLite with no setup for a single server, MySQL for a network, the four tables and what each one holds.
storage:
type: sqlite
mysql:
host: localhost
port: 3306
database: eventpulse
username: root
password: ""
use-ssl: false
pool-size: 8sqlite, the default, writes to eventpulse.db in the plugin's own folder and needs no setup. mysql is for a network that wants stats, history and pending rewards shared across servers, or for anyone who already runs a database. Both use the same tables.
| Key | What it does | Default |
|---|---|---|
type | sqlite or mysql | sqlite |
mysql.host | Address of the MySQL server | localhost |
mysql.port | Port it listens on | 3306 |
mysql.database | The database to use. Create it before starting the server. | eventpulse |
mysql.username | A user that can read and write to that database | root |
mysql.password | That user's password, empty if there is none | empty |
mysql.use-ssl | Only turn this on if the server needs an encrypted connection | false |
mysql.pool-size | How many connections to keep open | 8 |
Storage settings are read at startup only. A change of database needs a restart, not a reload. If the database cannot be opened, the plugin says so in the console and turns itself off rather than running without one.
Drivers download themselves
The connection pool and both database drivers are declared in the plugin's own plugin.yml and the server downloads them on the first start, so there is nothing to install and the jar stays small. A server that has no internet access on its first start cannot fetch them, and the plugin will not load until it can. Running the first start once with internet access, or copying the server's libraries folder from a machine that has, fixes that for good.
Tables
| Table | What it holds |
|---|---|
event_history | One row per finished event: the id, when it started and ended, whether it was a team event, and how many players scored |
event_scores | One row per player per event, with the score and the place. This is what /event top reads |
player_stats | One row per player: wins, participations, lifetime FarmPoints, and whether they want the scoreboard |
pending_rewards | One row per reward owed to a player who was offline when the event ended |
The history is also what the anti repeat rule reads on startup, so a restart does not let the same event come straight back. See Scheduling.
Nothing waits on the database
Every database call runs on its own thread, so a slow query never freezes the server. Scores are held in memory for the whole event and written once at the end, as one piece of work, so a server stopping right after an event cannot save half of a result. The lifetime numbers the placeholders and the board read come from a small cache, so drawing a scoreboard never waits on the database either.
Moving between the two
There is no built in migration. To move from SQLite to MySQL, copy the four tables across with any database tool, then change type and restart. The schema is the same on both.