20251220-ACT-02.md 3.4 KB

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.prismasys_role.
    • sys-user-role.prismasys_user_role.
    • sys-menu.prismasys_menu.
    • sys-role-menu.prismasys_role_menu.
    • sys-api-permission.prismasys_api_permission.
    • sys-role-api-permission.prismasys_role_api_permission.
    • sys-operation-log.prismasys_operation_log.
    • sys-login-log.prismasys_login_log.
    • sys-cache-sync-action.prismasys_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.