# 2025-12-20 ACT-02: MySQL → Mongo naming alignment
## Objectives
1. Keep existing `prisma/mysql/schema` files intact except for the explicitly deleted schema.
2. Align Prisma/Mongo naming so Mongo side reads `sys_*` but retains the original MySQL table names.
3. Drop unused `ImageConfig` schema once business confirms no dependency.

## Tasks
### A. Schema naming / retention
- Keep the existing MySQL Prisma files (`user.prisma`, `role.prisma`, etc.) under `prisma/mysql/schema`.
- When creating the Mongo-facing equivalents, rename as follows (with `@@map` to the original table names):
  - `sys-user.prisma` → maps to `sys_user`.
  - `sys-role.prisma` → `sys_role`.
  - `sys-user-role.prisma` → `sys_user_role`.
  - `sys-menu.prisma` → `sys_menu`.
  - `sys-role-menu.prisma` → `sys_role_menu`.
  - `sys-api-permission.prisma` → `sys_api_permission`.
  - `sys-role-api-permission.prisma` → `sys_role_api_permission`.
  - `sys-operation-log.prisma` → `sys_operation_log`.
  - `sys-login-log.prisma` → `sys_login_log`.
  - `sys-cache-sync-action.prisma` → `sys_cacheSyncAction`.

### B. Additional collection splits
- Extract `ProviderVideoSync` from `prisma/mysql/schema/main.prisma` into a dedicated `sys-providerVideoSync.prisma` whose `@@map` is `sys_providerVideoSync`.
- Ensure `cache-sync-action.prisma` becomes `sys-cache-sync-action.prisma` while mapping the table to `sys_cacheSyncAction` and preserving BigInt PK/indices.
- Do not migrate `sys_quota_log`; keep the MySQL schema file untouched and leave it out of Mongo plan.

### C. Clean-up rules
- Delete only `image-config.prisma` to remove the unused `image_config` table once the service no longer depends on it; do not touch other MySQL schema files.
- Update documentation to reflect new Mongo schema filenames and their MySQL table mappings.

### D. Verification & follow-up
- Draft a migration checklist enumerating which mgnt services still depend on each schema to ensure feature parity.
- Schedule follow-up on Mongo auto-increment/counters once naming is stabilized.

### E. Coding action plan
1. Add new Mongo-focused Prisma schema files under `prisma/mongo/schema/` using the `sys-*.prisma` names listed above, each importing the matching model definition and adding `@@map("<original_table>")` to preserve the existing table name; keep the existing MySQL files untouched for reference/use.
2. For `ProviderVideoSync`, move the model definition out of `prisma/mysql/schema/main.prisma` into `prisma/mongo/schema/sys-providerVideoSync.prisma` and ensure it maps to `sys_providerVideoSync`; update any import/usage in the Mongo Prisma client config if needed.
3. Replace `cache-sync-action.prisma` with `prisma/mongo/schema/sys-cache-sync-action.prisma` that maps to `sys_cacheSyncAction` while retaining the `id`, indexes, and payload JSON semantics; update Mongo Prisma client instantiation to load the new schema file.
4. Keep `sys_quota_log` only in MySQL schema (document it as excluded) and ensure no routing/logic tries to read the Mongo counterpart.
5. Delete `prisma/mysql/schema/image-config.prisma` as agreed; remove any references in documentation or migration scripts so future exports do not include the `image_config` table.
6. Update `docs/MGNT_MYSQL_TO_MONGO_MIGRATION.md` or related migration notes with the new filenames and mappings, plus the coding steps above so the implementation story is clear for tomorrow’s work.