Skip to content

Add the PostgreSQL Room and RaceSession schema #203

Description

@coder13

Part of #199.

Goal

Reshape the canonical Prisma/PostgreSQL model so rooms can own multiple independent race sessions without changing production read ownership yet.

Schema direction

  • Keep room identity, access, lifecycle, ownership, and optional competition association on app.rooms.
  • Add app.race_sessions with room, event, format/mode, scramble source, state, scheduled times, and actual start/end times.
  • Move current racing fields such as cube_event, started, and next_solve_at from their conceptual ownership on Room to RaceSession.
  • Add session-level participant state for competing, waiting, and eligibility/registration where required by the domain contract.
  • Make attempts reference race_session_id.
  • Keep solves related through attempts; remove or deprecate redundant room_id only through an expand-and-contract migration.
  • Preserve existing stable solve, attempt, room, and user identifiers.
  • Add the minimal competition association defined by the domain contract.

Migration requirements

  • Use additive Prisma migrations first.
  • Do not perform a destructive migration in application startup.
  • Keep the currently deployed application compatible during the expansion phase.
  • Add appropriate foreign keys, uniqueness constraints, and indexes for:
    • active sessions by room;
    • session attempt ordering;
    • user solve history;
    • competition-room session lookup;
    • migration reconciliation.
  • Define explicit delete/archive behavior. Historical solves must not cascade away because a room is hidden or archived.

Acceptance criteria

  • Prisma models and committed migrations represent the approved domain contract.
  • Existing PostgreSQL data remains readable during rollout.
  • A fresh PostgreSQL 17 database applies every migration with zero drift.
  • Upgrade tests run from the current production schema.
  • Foreign-key and uniqueness constraints reject invalid cross-room/session relationships.
  • Indexes cover active room/session and history read paths.
  • No migration deletes historical attempts or solves.
  • Rollback compatibility and the later contract phase are documented.

Dependencies

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: dataMongoDB, PostgreSQL, migrations, backfills, and data integrityarea: resultsSolves, scrambles, history, statistics, and exportsenhancementNew feature or requestpriority: P1High-priority work for the next delivery cycle

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions