Week 5 Worklog

Week 5 Objectives:

  • Backend: Build the UserWorkoutPlan module — personal plans with cloning from system templates, soft-delete, and one-active-plan enforcement.
  • Frontend: Build the plan management screens — MyPlansScreen, CreatePlanScreen, and PlanEditScreen with day-tabbed exercise editing.
  • Allow users to fully own their personal workout schedule with flexibility to create, clone, and customize plans.

Tasks to be carried out this week:

DayTaskStart DateCompletion DateReference Material
2- Build UserWorkoutPlan entity
  + Fields: user (@ManyToOne), name (≤150), description, goalTypeId (UUID), isActive (default true), isDeleted (default false)
  + Soft-delete via @SQLRestriction("is_deleted = false") — deleted plans invisible to all Hibernate queries
  + Write Flyway V1 migration: user_workout_plan, user_workout_plan_exercises tables		02/03/202602/03/2026
2- Write Flyway V2 migration: add is_deleted BOOLEAN DEFAULT FALSE to user_workout_plans02/03/202602/03/2026
3- Build UserWorkoutPlanExercise entity
  + Same scheduling fields as system: dayOfWeek, sets, reps, restSeconds, dayIndex, weekIndex, orderIndex
  + References Exercise (system entity), UserWorkoutPlan		02/04/202602/04/2026
3- Implement UserWorkoutPlanService key business logic
  + userId always extracted from Jwt.getSubject() → never from request body (IDOR prevention)
  + Clone: deep-copy all WorkoutPlanExercise entries into UserWorkoutPlanExercise — no FK to source plan retained
  + Activate: set isActive=true on target plan, set isActive=false on all other user plans (one-active rule)		02/04/202602/04/2026
4- Build UserWorkoutPlanController (/api/user-workout-plans)
  + POST /me — create new plan
  + POST /me/clone/{systemPlanId} — clone system template
  + GET /me (summary list), GET /me/active, GET /{id}
  + PUT /{id} (update metadata), PUT /{id}/activate, DELETE /{id} (soft)
  + POST /{planId}/exercises, GET /{planId}/exercises, PUT /{planId}/exercises/{id}, DELETE /{planId}/exercises/{id}		02/05/202602/05/2026
5- Build MyPlansScreen (Frontend)
  + Lists all user plans with active indicator badge
  + Activate/deactivate toggle; soft-delete with ConfirmModal
  + Navigate to CreatePlanScreen or PlanEditScreen		02/06/202602/06/2026
5- Build CreatePlanScreen (Frontend)
  + Form: plan name, description, goal type dropdown (fetched from GET /api/goal-types)
  + On submit: createMyPlan then navigate to PlanEditScreen		02/06/202602/06/2026
6- Build PlanEditScreen (Frontend)
  + Day-of-week tab bar (Mon-Sun) to switch exercise view per day
  + List exercises for selected day with reorder (up/down arrows), delete button
  + Navigate to PlanExercisePicker to add exercises for a given day
  + All changes call addExerciseToPlan, updatePlanExercise, removePlanExercise APIs		02/07/202602/07/2026

Week 5 Achievements:

  • Backend — UserWorkoutPlan module:
    • Flyway V1 + V2 migrations applied cleanly alongside Hibernate ddl-auto=create-drop.
    • Soft-delete pattern with @SQLRestriction works — deleted plans never appear in queries.
    • Clone endpoint creates a fully independent copy of system plans — verified by checking no FK pointer to source exists, ensuring robust customizability without mutating system data.
    • One-active-plan rule enforced at service layer — activating plan X correctly deactivates all others for that user.
    • userId always taken from the validated JWT sub claim — zero risk of IDOR attacks.
  • Frontend — Plan Management:
    • MyPlansScreen correctly shows active/inactive state; delete prompts confirmation modal.
    • CreatePlanScreen form validates name/description before submitting.
    • PlanEditScreen day-tab architecture allows intuitive per-day exercise management.
    • Reorder and remove operations reflect immediately in UI after API calls.
    • uiSlice (planEditorDay, plansReloadKey) keeps plan editor state in sync across navigator.

AWS Knowledge Learned:

  • Learned core Amazon RDS concepts for PostgreSQL production usage: managed backup, maintenance windows, parameter groups, and service limitations.
  • Understood database isolation through private subnets and security groups that only permit backend services to connect.
  • Studied snapshot and point-in-time recovery concepts to protect user-owned workout data from operator error or faulty releases.
  • Reinforced migration discipline by treating Flyway scripts as deterministic deployment artifacts that must behave safely across environments.
  • Learned why cloud database connections are a finite resource and why application-side connection pooling requires deliberate tuning.
  • Understood the future path toward read scaling through read replicas when reporting or analytics traffic increases.
  • Connected data retention and recovery strategy to product concerns such as auditability, reversibility, and long-term user trust.

In summary, week 5 linked application data design to AWS-managed relational database practices and recovery planning.

Next Week Plan:

  • Backend: Build the UserWorkoutSession and WorkoutLog modules for tracking live workout activity.
  • Frontend: Build PlanDetailScreen (active plan dashboard with day selector) and WorkoutSessionScreen (live workout screen with Redux session state).