Storage backends

Storage backends

ZDiscord persists four kinds of data: linked accounts, leaderboard stats, per-plugin key-value data, and reaction-role mappings. The first three are stored via a StorageManager abstraction; the last uses a plain YAML file.

YAML (default)

storage:
  type: "yaml"

Files are created in plugins/ZDiscord/:

• linked_accounts.yml — Minecraft UUID → Discord ID
• leaderboard_data.yml — Minecraft UUID → { stat → value }
• plugin_data.yml — arbitrary key-value pairs (ticket counter, status message ID, etc.)

Reads take a read lock briefly; writes take a write lock and schedule an asynchronous file flush. The flush is queued on the platform's async executor so it does not block the main thread.

MySQL

storage:
  type: "mysql"
  mysql:
    host: "localhost"
    port: 3306
    database: "zdiscord"
    username: "root"
    password: ""

Uses HikariCP with a pool of 10 connections. Tables are created on first run if they do not exist.

If the connection fails at startup, ZDiscord logs a warning and falls back to YAML for the lifetime of that process. The MySQL data is not lost — the next start will retry.

Schema

CREATE TABLE zdiscord_links (
    player_uuid VARCHAR(36) PRIMARY KEY,
    discord_id VARCHAR(20) NOT NULL,
    linked_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE zdiscord_stats (
    player_uuid VARCHAR(36) NOT NULL,
    stat_name VARCHAR(32) NOT NULL,
    stat_value BIGINT NOT NULL DEFAULT 0,
    PRIMARY KEY (player_uuid, stat_name)
);

CREATE TABLE zdiscord_data (
    data_key VARCHAR(128) PRIMARY KEY,
    data_value TEXT,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Reaction roles

Reaction-role mappings always use a plain YAML file at plugins/ZDiscord/reaction_roles.yml, regardless of the storage.type setting. They are not part of the StorageManager interface.

---

ZDiscord v1.1.0 · Home · Issues · Source