aether-data-schema
aether-data-schema is the logical schema generator for aether-data.
It owns:
- parsing
crates/aether-data/schema/logical/*.toml - validating table, column, index, unique constraint, and foreign-key metadata
- emitting driver-specific DDL for Postgres, MySQL, and SQLite
- checking that generated schema artifacts are current
- cleaning generated driver baseline directories before writing fresh output
It does not own runtime migrations or repository SQL. aether-data still owns
sqlx::migrate!, backfills, export/import, and repository implementations.
Commands
From the workspace root:
cargo run -p aether-data-schema --bin aether-schema -- check
cargo run -p aether-data-schema --bin aether-schema -- generate
cargo run -p aether-data-schema --bin aether-schema -- print --driver postgres
cargo run -p aether-data-schema --bin aether-schema -- print --driver mysql
cargo run -p aether-data-schema --bin aether-schema -- print --driver sqlite
The normal aether-data maintenance entrypoint wraps these:
bash crates/aether-data/schema/compose_schema.sh generate
bash crates/aether-data/schema/compose_schema.sh check
Source And Output
Input:
crates/aether-data/schema/logical/*.toml
Output:
crates/aether-data/schema/generated/README.md
crates/aether-data/schema/generated/{postgres,mysql,sqlite}/baseline/
Each logical TOML file becomes one generated .sql file per driver, and each
driver output directory gets a generated manifest.txt.
generated/** is machine-written. The generated directory README and each
generated SQL/manifest file state that the content should not be edited by hand.
Edit logical/*.toml instead.
The generator writes one manifest per driver output directory. A stale README,
stale generated file, or extra generated driver file is treated as an error by
aether-schema check.
Current Coverage
Logical schema now covers the clean baseline table set plus MySQL/SQLite table creation migrations:
- identity, API keys, audit logs, announcements, management tokens, preferences, and sessions
- provider catalog, provider keys/endpoints, model catalog, request candidates, Gemini file mappings, and video tasks
- auth config, OAuth providers, LDAP config, and OAuth links
- proxy nodes and proxy events
- wallet, payment, refund, redeem-code, and settlement snapshot tables
- usage capture and portable stats aggregation tables
Postgres-only historical follow-up migrations still live in driver-specific SQL until their shape is normalized or intentionally kept as overrides.