Overview
LandSandBoat uses a Python-based migration system managed bytools/dbtool.py. Migrations live in tools/migrations/ as individual .py files. They are loaded automatically in alphabetical (sorted) order.
Migrations handle transformations that cannot be expressed as a plain SQL INSERT … ON DUPLICATE KEY UPDATE — for example, renaming columns, restructuring character data blobs, or backfilling derived values.
Running migrations
With dbtool update (recommended)
dbtool.py update imports changed SQL files and runs all pending migrations in a single step:
Migrations only
To check and run pending migrations without re-importing SQL files:Express updates
Whentools/config.yaml contains a valid db_ver hash, dbtool.py update performs an express update:
- Compares the stored hash against the current
HEADusinggit diff. - Imports only the
sql/*.sqlfiles that changed between the two commits. - Runs any pending migrations.
- Updates
db_verto the newHEADhash.
db_ver is absent or invalid, dbtool.py update falls back to a full import.
Migration internals
Each migration module intools/migrations/ implements three functions:
During
run_all_migrations, dbtool calls check_preconditions and needs_to_run for each migration. Only migrations where needs_to_run returns True are executed. Results are printed to the terminal — green [*] for applied, red [ ] for pending.
If any migration produces errors, they are written to tools/migration_errors.log. This typically indicates corrupt character data rather than a code defect.
Docker deployments
In Docker Compose, thedatabase-update service runs dbtool.py update and must complete successfully before any server process starts:
config.yaml:
config.yaml with the current git hash:
Backup and restore
dbtool.py can create and restore database backups. Backups are stored as .sql files in sql/backups/.