🔧[기능추가][DB] 엔티티 삭제 Soft Delete 구현

[Chuseok22]

📝 현재 문제점

• 도메인(예: 공연장, 공연 등)에 대한 Delete 로직이 미구현입니다.
• 물리 삭제 시 이력 추적/복구가 어려워 운영 리스크가 있습니다.
• Hibernate의 @SoftDelete, @SQLDelete, @Where를 사용하지 않고 수동으로 Soft Delete를 적용해야 합니다.
• 현재 중복 검증(validateConcertName → existsByConcertName)과 조회 쿼리들이 “삭제된 데이터”를 고려하지 않아 향후 Soft Delete 도입 시 충돌/노출 가능성이 있습니다.

🛠️ 해결 방안 / 제안 기능

• Soft Delete 마커 컬럼 추가

  • 옵션 A: isDeleted BOOLEAN DEFAULT false
  • 옵션 B: deletedAt TIMESTAMP WITH TIME ZONE (+ 필요 시 deletedBy UUID 또는 VARCHAR)
  • 결정 필요: 위 A/B 중 택1(또는 병행). 운영/감사 요구사항에 맞춰 선택해 주세요.

• 조회/검증 경로 전면 반영

  • findConcertById, filteredConcertForAdmin, findConcertInfoByConcertIdForAdmin 등 모든 조회 쿼리에 “삭제 아님” 조건 수동 추가.
  • validateConcertName → “삭제 아님” 조건을 포함한 중복 검증으로 수정(삭제된 데이터는 중복으로 보지 않음).

• Repository/쿼리 리팩토링

  • 예: existsByConcertNameAndIsDeletedFalse(...), findByConcertIdAndIsDeletedFalse(...) 등 명시적 메서드 도입.
  • ConcertRepositoryCustom JPQL/QueryDSL에도 isDeleted = false(또는 deletedAt IS NULL) 조건 수동 추가.

• DB 마이그레이션

  • Soft Delete 컬럼 추가 및 인덱스 보강.

  • 고유 제약과의 충돌 방지(썸네일/좌석 배치도 경로 unique = true):

    • 동일 경로 재사용 가능 정책 여부 결정 필요.
    • 재사용 허용 시, “활성 레코드 한정 고유”가 필요(예: 부분 고유 인덱스 또는 애플리케이션 레벨 검증).

• API 설계

  • DELETE /admin/concerts/{concertId} (Soft Delete)
  • 권한 체크(관리자 한정), 멱등성 보장(이미 삭제 시 적절한 응답 규약 정의).

• 테스트/운영 가이드

  • 단위/통합 테스트: 삭제/조회/중복검증/캐시/임베딩 상호작용 검증.
  • 운영: 삭제 후 검색 결과/관리자 리스트에서 노출되지 않음을 확인.

⚙️ 작업 내용

🙋‍♂️ 담당자

• 백엔드: @Chuseok22
• 프론트엔드: 이름
• 디자인: 이름

[Chuseok22]

#581 이슈에서 회원 탈퇴 기능 구현하며, is_deleted 필드 작업 진행합니다