Switch Database Provider
Evidence status: The Rust SQLite 4.1.1 baseline is executed, but an actual
provider-to-provider switch has not been recorded. Java execution and every
non-SQLite combination remain pending.
Problem
Move a generated TeaQL application to another relational provider without leaking provider APIs into business queries or assuming identical operational semantics.
Before Switching
Record the current baseline:
- model and generator revision;
- generated dependency set;
- current and target provider/database versions;
- schema-management mode;
- transaction and graph-write tests;
- query, aggregate, ordering, pagination, and ID-generation behavior;
- production connection and migration settings.
Java Path
Java provider selection can involve three separate layers:
- Model data-service selection where the generator uses it.
- Runtime/database module and JDBC driver dependency.
- Host-framework datasource configuration.
Do not copy the MySQL driver version from an old example. Select a driver supported by the target Java/framework/database baseline and record it in the compatibility evidence.
After changing the model or generator configuration, regenerate and review:
- provider/runtime dependencies;
- generated metadata;
- SQL dialect selection;
- datasource properties;
- schema output.
Rust Path
Choose a documented provider candidate during runtime assembly. Only the SQLite combination recorded in Database Provider Compatibility has maintained execution evidence here; the names in this table do not declare a tested version range.
| Backend | Documented provider candidate |
|---|---|
| PostgreSQL | teaql-provider-postgres |
| MySQL | teaql-provider-mysql |
| SQLite | teaql-provider-sqlite |
| No-database tests | MemoryRepository in teaql-runtime |
Older teaql-provider-sqlx-* and teaql-provider-rusqlite names are historical
and should not be introduced into a newly generated workspace.
Use dependency versions emitted by the target generator, then register the
provider in runtime assembly. Keep Q business queries provider-agnostic.
Verification Matrix
| Behavior | Required check |
|---|---|
| Schema | Use dry-run/verification where supported; inspect types, nullability, indexes, and identifiers. |
| Basic query | Filter, projection, ordering, pagination, and intent metadata. |
| Relations | Nested selection and association loading. |
| Aggregates | Count, sum, grouping, and provider-specific numeric behavior. |
| Mutation | Insert, update, optimistic locking, delete/recover if used. |
| Graph transaction | Child failure rolls back the complete graph. |
| IDs | Generation remains unique and compatible with existing data. |
| Time/text | Timestamp zones, collation, case sensitivity, Unicode, and ordering. |
| Operations | Pooling, timeout, TLS, retry, logging, and credentials. |
Rollback
Provider rollback may require more than reverting dependencies:
- preserve old datasource/provider configuration;
- avoid destructive schema changes without database rollback scripts;
- verify data types written by the new provider remain readable;
- retain the previous generated workspace or reproducible generator inputs;
- define a smoke-test threshold for rollback.