EDU-006 — Deliver Practice schema through module-owned Flyway

Status: done — V4030 delivered and verified on an isolated disposable PostgreSQL test database
Type: database implementation
Phase: 2 prerequisite
Blockers: EDU-005

Implementation result

V4030__create_and_adopt_practice_schema.sql now owns the final Practice session/question, report/detail, wrong-question/idempotency, favorite, and unified idempotency schema. Fresh databases do not create legacy answer/submit idempotency tables. Compatible manually initialized Practice tables receive missing final columns and JSONB alignment; legacy answer/submit idempotency rows are backfilled into education_idempotency while the source tables remain untouched. A conflicting request hash fails the migration transactionally.

The EDU-016 test seam now runs the real Flyway chain in a random disposable PostgreSQL schema. Its temporary create_tables.sql bridge was removed. The established 140 persistence tests and five migration-contract scenarios pass together.

Manual Education SQL mounts were removed from Docker Compose, and the active Education README and Pilot runbook now describe PostgreSQL/Flyway forward-only delivery. V4010/V4020 remained byte-for-byte unchanged. V4040 was not created because the capability menu still lacks a complete admin UI/product decision; no empty placeholder version was introduced.

No shared or production database was migrated. Successful migration evidence applies only to the isolated no-volume PostgreSQL container and random schemas used by the tests.

Scope

Implement only the objects approved in EDU-005, potentially covering:

practice sessions and question snapshots;
answer and submit idempotency;
reports and report details;
wrong questions and favorites;
tenant-scoped unique constraints;
indexes required by verified query paths;
necessary menu/permission seed data;
compatible backfills for existing development data.

Exact objects and versions are determined by EDU-005 and flyway-postgresql.

Architecture rules

Use PostgreSQL dialect only.
Tenant-scoped uniqueness includes tenant_id where required.
Database uniqueness is the final idempotency guard.
Use ON CONFLICT where approved by the design.
Do not copy Supabase auth/RLS as the application isolation model.
Do not add destructive rollback migrations.

Acceptance criteria

New migrations use versions allocated by flyway-postgresql.
V4010/V4020 remain unchanged as potentially distributed history.
Migrations are packaged under target/classes/db/migration/education/.
Annotated SQL and Mapper behavior match PostgreSQL constraints.
Focused repository/integration tests cover uniqueness and tenant scope.
Real PostgreSQL Flyway migrate/validate succeeds in an isolated disposable test environment.
Operational docs no longer instruct users to apply MySQL or manual Education SQL for these objects.

Verification

At minimum:

git diff --check
mvn -pl yudao-module-education -am -DskipTests clean package
find yudao-module-education/target/classes/db/migration/education -type f
mvn -pl yudao-server -am -DskipTests clean compile

Also run the PostgreSQL commands prescribed by flyway-postgresql when an authorized database is available.

Verification performed

Against an isolated PostgreSQL container bound only to 127.0.0.1, the focused Flyway suite exercised fresh migration, baseline-4009 adoption, compatible session/question plus legacy-idempotency adoption, conflict with existing unified history, and conflicting duplicate legacy keys. Together with the existing persistence suite: 145 tests passed, 0 failures, 0 errors, 0 skipped. Every test schema was dropped and the no-volume container was stopped.

Also completed:

mvn -pl yudao-module-education -am -DskipTests clean package — BUILD SUCCESS
V4010, V4020, V4030 present under target/classes/db/migration/education/
mvn -pl yudao-server -am -DskipTests clean compile — BUILD SUCCESS
git diff --check — passed

V4010 and V4020 retained their pre-ticket SHA-256 values. No shared or production PostgreSQL database was changed.

Risk and rollback

Risk: High data compatibility and deployment-order risk.
Rollback: Forward correction migration plus application rollback. Never use clean or destructive rollback in shared environments.

4.4 KiB Raw Blame History