Storage
Where pending blocks are stored, and choosing SQLite or MySQL.
RegenZones needs somewhere durable to keep track of blocks waiting to regenerate, so a
restart or a crash never loses them. That is handled entirely through the storage
section of config.yml.
storage:
type: sqlite
mysql:
host: localhost
port: 3306
database: regenzones
username: root
password: ""
pool-size: 10SQLite (default)
type: sqlite needs no setup. RegenZones creates and manages its own database file
inside the plugin folder. This is the right choice for almost every server.
MySQL (optional)
Set type: mysql and fill in the mysql block to use a MySQL server instead.
| Key | What it controls |
|---|---|
host | MySQL server address |
port | MySQL server port |
database | Database name, created ahead of time on your MySQL server |
username | Login username |
password | Login password |
pool-size | Connection pool size |
MySQL is worth using if you already centralise plugin data across multiple servers, or you want pending blocks visible outside the plugin. For a single server, SQLite is simpler and needs nothing extra.
What actually gets stored
One row per pending block: world, coordinates, the original block's captured data, the temporary block or blocks it was swapped to, when it was swapped, and the timestamp it should restore at. Both block data columns are full BlockData strings (or an ItemsAdder id, if that block was a custom one), not just a material name. A rule with growth stages keeps every stage in the temporary column, one per line.
Tables from before 1.0.0-5 are upgraded in place on first start: a placed_at column is
added, and on MySQL the temporary block column is widened from VARCHAR(64) to TEXT,
which a long BlockData string or a list of stages needs. Nothing else about your world is stored. See
Regeneration Engine for how these rows are written and
cleared.