Database-History: add internals section on stable keys vs. local check IDs
Operators copying between databases (mysqldump | mysql, pg_dump | psql,
or just rsync'ing a SQLite file with intent to merge) need to know that
the check_id column is database-local, not portable. Two databases
assign different IDs to the same stable_key, so a raw row copy silently
mis-attributes every violation.
Calls out /grim history copy as the right tool — it walks the source's
checks table and rewrites check_id references on the way through.
Also notes that SessionRecord IDs (UUIDs) and player UUIDs ARE portable;
the warning is specific to the integer check_id column.
Database wiki: SQLite file portability across server versions
History page gets a subsection explaining that the schema is identical
regardless of MC version. Modern (>=3.24, ON CONFLICT) and legacy (<3.24,
INSERT OR IGNORE + UPDATE) writer dialects produce byte-equivalent rows,
and a data.db file from a 1.8 server can be moved to a 1.21+ server (or
vice versa) with no migration step. The dialect picks itself at init
from sqlite_version().
Database wiki section: overview + History subsystem
Adds two operator-facing pages plus sidebar entries:
- Database.md: backend matrix (SQLite/MySQL/Postgres/Mongo/Redis), which
drivers ship bundled with which server flavour vs need a holder mod,
per-platform install instructions, the SQLite engine version floor
(3.24.0, met by CraftBukkit 1.13+), backend-by-backend database.yml
config snippets, JDBC-URL gotchas (useSSL, allowPublicKeyRetrieval,
reWriteBatchedInserts), startup verification, and a roadmap note on
per-category failure isolation.
- Database-History.md: the /grim history command tree (list, page,
session detail with --detailed/--verbose flags, latest alias),
what's stored per session/violation, retention windows, performance
notes per backend, customisation via messages.yml grim-history-* keys.
The Database entry sits between Configuration and Discord-webhooks in
the sidebar, with History indented as a subpage. Settings is reserved
as a future sibling once that subsystem ships.
