refactor(data): remove MySQL and SQLite support

Use PostgreSQL as the only database backend across runtime, schema tooling, installation, Compose, and CI. Update regression tests and reject removed drivers explicitly.
This commit is contained in:
elky
2026-09-07 00:09:42 +08:00
parent b5ed802277
commit 2281f2b754
298 changed files with 793 additions and 134804 deletions
+25 -46
View File
@@ -16,21 +16,21 @@ task crates live in the sibling `../contracts` crate (`aether-data-contracts`).
| `src/database.rs` | Logical SQL driver selection and shared pool configuration. |
| `src/config.rs` | Data-layer config for SQL drivers and repository wiring. |
| `src/maintenance.rs` | Maintenance DTOs and aggregation summaries used by backend dispatch and runtime maintenance entrypoints. |
| `src/driver/{postgres,mysql,sqlite}.rs` | Thin compatibility facades for the selected adapter crates. Low-level pools, transactions, and leases live in `aether-data-postgres`, `aether-data-mysql`, and `aether-data-sqlite`. |
| `src/driver/postgres.rs` | Thin compatibility facades for the selected adapter crates. Low-level pools, transactions, and leases live in `aether-data-postgres`. |
| `src/repository` | Compatibility modules that re-export contracts and selected SQL adapters, plus concrete in-memory implementations. Driver-specific request-path SQL lives in the adapter crates. |
| `src/backend` | Composition root. Builds concrete driver backends and exposes app-facing read/write/worker/lock/lease handles. |
| `src/backend/{maintenance,stats,wallet,system}.rs` | Backend-owned maintenance, aggregation, wallet ledger, and system config workflows that are not normal request-path repositories. |
| `src/lifecycle/migrate.rs` and `src/lifecycle/migrate/*` | Compatibility entry points and Postgres snapshot bootstrap adapter. |
| `src/lifecycle/backfill.rs` | Backfill entry points and backfill discovery. |
| `src/lifecycle/export.rs` | Cross-database export/import workflows. |
| `../adapters/{postgres,mysql,sqlite}/migrations` | Executable `sqlx` migrations owned and embedded by each adapter crate. |
| `../adapters/postgres/migrations` | Executable `sqlx` migrations owned and embedded by each adapter crate. |
| `schema` | Schema maintenance workspace for logical definitions, driver fragments, and generated output. |
| `schema/logical` | Human-maintained logical table definitions used by `aether-data-schema`. |
| `schema/drivers/{postgres,mysql,sqlite}` | Human-maintained driver fragments that compose back into executable SQL while generation is being promoted. |
| `schema/drivers/postgres` | Human-maintained driver fragments that compose back into executable SQL while generation is being promoted. |
| `schema/bootstrap/postgres` | Human-maintained source fragments for the Postgres bootstrap snapshot. `build.rs` composes them into the runtime embedded artifact during crate builds. |
| `schema/generated` | Machine-written SQL generated from logical schema for audit and drift detection only. |
| `schema/overrides` | Rare driver-specific SQL escape hatch. Keep README-only until a real override is needed. |
| `backfills/{postgres,mysql,sqlite}` | Executable backfill SQL grouped by driver. |
| `backfills/postgres` | Executable backfill SQL grouped by driver. |
## Layering Rules
@@ -39,11 +39,10 @@ The crate is easiest to read as five layers:
1. Contracts: DTOs, input structs, repository traits, and `DataLayerError`.
Prefer `aether-data-contracts` for anything that another crate needs to
compile against.
2. Driver primitives: `aether-data-postgres`, `aether-data-mysql`, and
`aether-data-sqlite` connect to infrastructure and expose pools, runners,
2. Driver primitives: `aether-data-postgres` connect to infrastructure and expose pools, runners,
and executable migrations;
the matching `src/driver/*.rs` files only preserve the existing import paths.
3. Repository implementations: `aether-data-{postgres,mysql,sqlite}` translate
3. Repository implementations: `aether-data-postgres` translate
contract types to driver-specific SQL. `src/repository/<domain>` keeps the
compatibility import path and owns the in-memory implementation where one
exists.
@@ -68,8 +67,6 @@ src/repository/<domain>/
mod.rs # exports trait/type names and concrete implementations
types.rs # implementation-local DTOs when they are not already in contracts
postgres.rs # Postgres implementation
mysql.rs # MySQL implementation
sqlite.rs # SQLite implementation
memory.rs # tests/dev in-memory implementation
```
@@ -78,49 +75,31 @@ new generic `sql.rs` modules for driver-specific code.
## SQL Driver Policy
The project supports three SQL drivers at the repository/backend boundary:
Postgres, MySQL, and SQLite. That does not mean every raw SQL file is shared.
The portable contract is the Rust shape and behavior; the physical SQL stays
driver-specific where syntax, indexes, JSON support, timestamps, locking, or
upsert semantics differ.
The repository/backend boundary supports PostgreSQL only. Repository contracts
remain independent of SQLx, while physical SQL, pools, and migrations belong to
`aether-data-postgres`.
Use logical types in design docs and reviews:
| Logical type | Postgres | MySQL | SQLite |
|---|---|---|---|
| `json` | `json` or `jsonb` | `json` or text JSON | text JSON |
| `bool` | `boolean` | `boolean` / `tinyint(1)` | integer |
| `time_unix` | `bigint` or legacy timestamp | `bigint` | integer |
| `money_decimal` | `numeric` / legacy double | `double` | real |
`jsonb` is acceptable only in Postgres SQL. MySQL and SQLite migrations must not
contain `jsonb`; this is guarded by migration tests. Prefer `serde_json::Value`
or typed Rust structs at the repository boundary so callers do not depend on the
physical storage type.
| Logical type | PostgreSQL |
|---|---|
| `json` | `json` or `jsonb` |
| `bool` | `boolean` |
| `time_unix` | `bigint` or timestamp |
| `money_decimal` | `numeric` / legacy double |
### Feature Matrix
`aether-data` enables only PostgreSQL by default so local checks do not compile
all SQLx drivers:
`aether-data` enables PostgreSQL by default. The `all-drivers` feature selects
the same PostgreSQL backend; a no-driver build remains available for pure
in-memory repository tests.
```bash
cargo check -p aether-data
cargo check -p aether-data --no-default-features --features mysql
cargo check -p aether-data --no-default-features --features sqlite
cargo check -p aether-data --no-default-features --features all-drivers
cargo check -p aether-data --no-default-features
cargo check -p aether-data --no-default-features --features postgres
```
Services selecting MySQL or SQLite in `Cargo.toml` must also disable the default
Postgres feature:
```toml
aether-data = { workspace = true, default-features = false, features = ["mysql"] }
```
The gateway explicitly enables `all-drivers` for deployment compatibility. New
services should select only the driver they deploy with. A configured driver
that is not enabled in the build returns an explicit configuration error rather
than silently constructing an empty backend.
Database URLs must use `postgres:` or `postgresql:`. Unsupported drivers and
URL schemes fail explicitly instead of falling back to another backend.
## Schema Maintenance
@@ -147,11 +126,11 @@ normal driver fragments.
`compose_schema.sh check` also verifies that required baseline/portable
table-creation SQL is represented in `schema/logical`. This is the guardrail
that keeps table structure from drifting back into three manually maintained
that keeps table structure from drifting back into multiple manually maintained
definitions.
For executable fragments that have not been promoted to generated output yet,
edit fragments under `schema/drivers/{postgres,mysql,sqlite}` directly, run
edit fragments under `schema/drivers/postgres` directly, run
`compose`, then run `check`. Do not edit baseline executable SQL and fragments
independently.
@@ -172,7 +151,7 @@ When adding a table:
## Known Cleanup Targets
These are intentionally staged to keep the multi-database refactor reviewable:
These are intentionally staged to keep the data-layer refactor reviewable:
1. Retire the compatibility re-export paths once downstream crates use
`aether-data-contracts` for contracts and `aether-data` only as the runtime