Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/TaylorZaneKirk/MMO-Project/llms.txt

Use this file to discover all available pages before exploring further.

MMO Project uses plain numbered SQL files as additive migrations. There is no migration framework — scripts are applied in ascending order using psql, and each file is purely additive. No migration in the prototype drops columns, truncates tables, or performs destructive schema changes. The entire schema history is reproducible by replaying the files from 001 to the highest available number against a fresh database.

​
Migration inventory

FilePurpose
001_initial_schema.sqlClean bootstrap schema for a fresh prototype database
002_equipment_schema.sqlAdditive migration for equipment slot definitions and per-character equipment state
003_item_equipment_metadata.sqlAdditive migration for original-script-derived item equipability metadata
004_leg_item_definitions.sqlAdditive seed migration for generated leg equipment item definitions
005_food_item_definitions.sqlAdditive seed migration for implemented food consumable item definitions
006_ground_items_schema.sqlAdditive migration for dropped world items and owner-first visibility timing
007_ground_item_visibility_notifications.sqlAdditive compatibility migration for automatic public drop reveal notifications
008_skill_equipment_schema.sqlAdditive migration for equipment-derived skill bonuses
009_hand_asset_slot_alignment.sqlAdditive correction migration aligning hand equipment metadata to the actual player actor asset folders
010_runtime_revision_streams.sqlAdditive migration for revisioned character/map runtime delta streams

​
Applying migrations

1

Connect to your local PostgreSQL database

Open a terminal and connect to the prototype database:
psql -d mmo_project_proto
2

Apply each file in order

Inside the psql session, source each migration file in numerical order:
\i prototype/sql/001_initial_schema.sql
\i prototype/sql/002_equipment_schema.sql
\i prototype/sql/003_item_equipment_metadata.sql
\i prototype/sql/004_leg_item_definitions.sql
\i prototype/sql/005_food_item_definitions.sql
\i prototype/sql/006_ground_items_schema.sql
\i prototype/sql/007_ground_item_visibility_notifications.sql
\i prototype/sql/008_skill_equipment_schema.sql
\i prototype/sql/009_hand_asset_slot_alignment.sql
\i prototype/sql/010_runtime_revision_streams.sql
3

Or apply all files in a single shell loop

From the repository root, run all migration files in glob order without opening an interactive session:
for f in prototype/sql/*.sql; do psql -d mmo_project_proto -f "$f"; done

​
Adding a new migration

1

Create the new file

Create prototype/sql/NNN_description.sql where NNN is the next sequential number (e.g. 011). Use a short snake_case description that matches the dominant change.
2

Write only additive DDL

The prototype migration convention allows only:
  • CREATE TABLE (new tables)
  • ALTER TABLE ... ADD COLUMN (new columns on existing tables)
  • CREATE INDEX (new indexes)
  • INSERT seed data
Do not include DROP TABLE, DROP COLUMN, TRUNCATE, or any statement that removes existing data or schema.
3

Record module ownership

Open prototype/sql/MODULE_OWNERSHIP.md and add an entry for any new table, mapping it to the application layer that owns it. If the table crosses an existing module boundary, stop and confirm the boundary is intentional before proceeding.
4

Apply and verify locally

Apply the new file to your local database and confirm it runs without errors:
psql -d mmo_project_proto -f prototype/sql/NNN_description.sql

​
Module ownership

Each SQL table is owned by a specific application layer defined in prototype/sql/MODULE_OWNERSHIP.md. Check that file before adding a new table to understand which server module should be its primary consumer. If a table gains consumers outside its designated boundary during the prototype checkpoint, stop and review whether module responsibilities are drifting beyond the approved slice.
The prototype schema does not use a migration framework. Always apply migrations in numerical order. Never modify already-applied migration files — create a new numbered file instead.

Build docs developers (and LLMs) love

Get started for freeTalk to us