삭제 로직 구현 방식 선택 과정에서 고민이 있었던 문제
문제 |
삭제 기능 구현 시 existsById() + deleteById() 방식(쿼리 2번)과 findById() + delete() 방식(쿼리 1번) 중 어떤 방식이 더 적절한지 판단이 필요했음.
원인 |
각 방식의 특성이 달라 상황에 따라 선택 기준이 다름.
existsById()는 쿼리는 2번이지만 전체 컬럼을 조회하지 않아 속도 면에서 유리하고, findById()는 전체 컬럼을 조회해 Java 객체로 만들기 때문에 쿼리는 1번이지만 상대적으로 무거움.
(프론트에서 존재를 보장하고 넘어오는 구조라면 deleteById() 하나로 단순화하는 것도 유효한 선택.)
해결 방법 |
방어적 예외처리를 우선시해 existsById() + deleteById() 방식을 선택함. 전체 컬럼을 조회하지 않아 속도 면에서 findById() 대비 유리하고, 존재하지 않는 id로 요청이 들어왔을 때 명확한 예외 메시지를 반환할 수 있음. User와 Schedule 양쪽 모두 동일한 방식으로 통일해 일관성도 확보함.
DTO가 Entity를 직접 참조하는 문제
문제 |
SchdulePageResponseDto 만 생성자에서 Schedule 엔티티를 직접 받아 내부 값을 꺼내는 방식으로 구현을 했었음. 나머지 DTO는 전부 필드 값을 직접 받는 방식이라 패턴이 일관되지 않았음.
원인 |
페이징 응답 DTO 작성 시 편의상 엔티티를 그대로 넘겨 처리함. DTO가 엔티티를 알게 되면 엔티티가 변경될 때 DTO도 함께 수정해야하는 문제가 있다는걸 깨달음.
해결 방법 |
SchedulePageResponseDto가 값만 받도록 수정하고, 엔티티 -> DTO 변환은 Service 로직에서 담당하도록 변경함. "DTO는 값만 담는 그릇, 엔티티를 모르는 것이 원칙"을 기준으로 삼음.
JPA Auditing 누락으로 생성/수정 시간 미반영
문제 |
일정 생성 API 호출 시 응답 데이터의 createdAt, updatedAt 값이 null로 반환됨.
원인 |
BaseEntity에 @CreatedDate, @LastModifiedDate 어노테이션을 통해 JPA Auditing을 설정 했으나, 이를 활성화하는 @EnableJpaAuditing어노테이션을 메인 애플리케이션 클래스에 추가하지 않아서 발생했던 것이였음.
해결 방법 |
메인 애플리케이션 클래스에 @EnableJpaAuditing어노테이션을 추가해서 JPA Auditing을 활성화함.
@OneToMany 누락으로 애플리케이션 실행 실패
문제 |
일정 페이징 조회 구현을 위해 Schedule 엔티티에 comments 필드 추가 후 애플리케이션 실행 시 아래 오류가 발생함.
Basic collection has element type 'Comment' which is not a known basic type원인 |
JPA 엔티티 간 연관관계를 매핑할 때 반드시 관계를 나타내는 어노테이션 (@OneToMany, @ManyToOne등)이 필요함. comments 필드에 @OneToMany 어노테이션 없이 List<Comment> 타입만 선언해서 JPA가 해당 필드를 일반 컬렉션으로 인식하지 못함.
해결 방법 |
@OneToMany(mappedBy = "schedule") 추가하여 Comment와의 연관관계를 명시함.
