[areumz]

Phase 8 — JPA + MySQL 전환 (최종 성공 지표)

메모리 구현체를 JPA/MySQL 구현체로 교체. Phase 1에서 설계한 Repository 인터페이스가 옳았는지 검증하는 단계.

완료한 작업

• MySQL 설치 및 devqueue 데이터베이스 생성
• spring-boot-starter-data-jpa + MySQL 드라이버 의존성 추가
• DB 연결 정보를 application-local.properties로 분리 (.gitignore 처리, .example 템플릿 제공)
• Article/User/Vocabulary에 @Entity/@Id/@GeneratedValue/@Enumerated(STRING) 부착
• SpringDataJpaXxxRepository + JpaXxxRepository(어댑터) 작성
• @Profile("memory")/@Profile("jpa")로 구현체 전환 가능하게 구성
• Phase 1의 Repository 계약 테스트를 JPA 구현체에서 재실행하여 통과 확인

겪은 이슈와 해결

1. read가 MySQL 예약어와 충돌 — @Column(name = "is_read")로 자바 필드명은 유지하며 DB 컬럼명만 분리
2. ddl-auto=create로 인한 데이터 유실 — update로 변경하여 재시작 시 데이터 보존
3. JPA에서 필드 변경이 DB에 반영되지 않는 문제 — 메모리 구현체는 참조를 공유해 필드 변경이 즉시 반영됐지만, JPA는 트랜잭션 경계 안에서만 변경 감지(dirty checking)가 동작함을 확인. toggleMemorized, updateMemo, toggleRead, updateArticle, updatePopupDate 등 "조회 후 필드만 변경"하는 모든 메서드에 @Transactional 추가
4. 세션에 저장된 객체와 DB에서 새로 조회한 객체가 별개 인스턴스인 문제 — 로그인 팝업 날짜 갱신 시, DB 반영과 별개로 세션의 loginUser 객체도 직접 갱신하도록 수정

학습 개념

@Entity/@Id/@GeneratedValue/@Enumerated(STRING), JpaRepository<T,Long>, Spring Data JPA 쿼리 메서드(findByUsername, findByArticleId 자동 구현), @Profile을 통한 구현체 전환, @Transactional과 영속성 컨텍스트/dirty checking, MySQL 예약어 회피

완료 기준 (DoD) — 최종 성공 지표

• Controller/Service 코드를 한 줄도 바꾸지 않고 구현체 교체만으로 애플리케이션이 동일하게 동작함
• Phase 1의 Repository 계약 테스트가 JPA 구현체에서도 통과
• 서버 재시작 후에도 데이터(회원, 글, 단어, 암기 상태)가 그대로 유지됨 확인

참고

• 계획 문서: rpi/article-vocab-tracker/plan/PLAN.md (Phase 8)