Persistence/Storage

The plugin supports multiple storage backends for tracking which collectables each player has unlocked.

This is configured in your main config.yml under the storage: block.

Supported Backends

FLATFILE (default)
- Saves player data into YAML files under playerdata/collectables/
- Simple and portable, good for small servers
SQLITE
- Stores data in a relational database
- Supports SQLite (bundled in the plugin jar), via JDBC
- MySQL, and MariaDB can be supported later if needed or extended through the Codex API

Config Structure

storage:
  backend: FLATFILE   # FLATFILE | SQLITE

  flatfile:
    dir: playerdata/collectables
    # directory path relative to the plugin folder

  sql:
    jdbcUrl: jdbc:sqlite:${plugin.data}/collectables.db
    username: ''
    password: ''
    pool:
      maxSize: 6
      minIdle: 2

Fields

Field	Notes
`backend`	Selects which storage mode to use: `FLATFILE` or `SQL`
`flatfile.dir`	Directory where YAML files are saved (per-player)
`sql.jdbcUrl`	JDBC URL. Defaults to SQLite with a database file inside the plugin folder
`sql.username/password`	Credentials for MySQL/MariaDB. Leave empty for SQLite
`sql.pool.*`	HikariCP connection pool options. Tune for your DB load

Using SQLite

If you want SQLite, make sure you’re running the plugin jar that includes the SQLite driver:

CollectablesCodex-with-sqlite.jar
By default, it stores data in plugins/CollectablesCodex/collectables.db
No extra setup required

Supported Backends

Config Structure

Fields

Using SQLite

See Placeholders for using System properties/env variables for config values.