📌Spring 입문 과제 트러블슈팅

비밀번호가 일치해도 삭제가 안되는 문제

삭제 기능 테스트 도중, 올바른 비밀번호를 입력해도 404 에러가 뜨는 문제가 있었다. 404 에러를 던지도록 설정한 부분은 DB에 있는 비밀번호와 입력한 비밀번호가 틀리는 경우 발생한다.

이것저것 시도해보다 Repository Layer에서 정확한 scheduleId와 password가 출력되는 것을 확인한 후, 비밀번호를 검증하는 Service Layer에서 다음과 같이 출력해봤다.

System.out.println("db password = " + current.getPassword());
System.out.println("input password = " + password);
System.out.println("equals = " + current.getPassword().equals(password));

그 결과는 다음과 같았다. JSON 형식의 문자열이 그대로 들어온 것이다.

Controller에서 보니 비밀번호를 String 그대로 넣은 것이 문제였다.

@DeleteMapping("/{scheduleId}")
public ResponseEntity<Void> deleteSchedule(
        @PathVariable Long scheduleId,
        @RequestBody(required = false) String password
) {
    scheduleService.deleteSchedule(scheduleId, password);![](https://velog.velcdn.com/images/3uomlkh/post/36205978-55e3-4764-b9d5-e29b265f8e2f/image.png)

    return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}

• inputPassword → {"password": "1111"} (JSON 객체)
• dbPassword → "1111" (String)

따라서 String 타입이 아닌 ScheduleRequestDto 타입으로 변경한 뒤 dto에서 getPassword()를 해서 비밀번호만 넘겨주었다.

@DeleteMapping("/{scheduleId}")
public ResponseEntity<Void> deleteSchedule(
        @PathVariable Long scheduleId,
        @RequestBody ScheduleRequestDto dto
) {
    scheduleService.deleteSchedule(scheduleId, dto.getPassword());
    return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}

변경 후 다시 로그를 출력해보니 원하던 결과가 나왔다.

또한 Postamn에서의 테스트도 성공하였다.

이 과정을 통해 @RequestBody String 대신 DTO 객체를 사용하는 것이 좋다는 것을 알게 되었다.

여기서 또 수정된 부분이 있는데, required = false로 적은 부분을 삭제한 부분이다. @RequestBody(required = true) 가 설정되어 있으면, 클라이언트는 JSON을 반드시 보내야 하지만, 특정 필드는 null이 될 수도 있다. 이때, @RequestBody(required = false)로 변경하면 요청 본문이 없어도 예외가 발생하지 않는다. 비밀번호가 선택 사항이라면 false로 하는 것도 고려할 수 있지만 보통 비밀번호는 필수값이기 때문에 사용하지 않는다.

queryForObject() vs query()

예외 처리를 구현하는 도중, 원하는 곳에서 예외가 발생하지 않고 엉뚱한 곳에서 발생해서 그 원인을 찾아보았다.

일정을 수정하는 부분 중 findScheduleByIdWithPassword()에서 내가 설정한 ScheduleNotFoundException이 아니라 EmptyResultDataAccessException이 났다.

@Transactional
@Override
public ScheduleResponseDto updateSchedule(Long scheduleId, ScheduleRequestDto dto) {
    Schedule current = scheduleRepository.findScheduleByIdWithPassword(scheduleId);

    if (current == null) {
        throw new ScheduleNotFoundException("수정할 일정이 존재하지 않습니다.");
    }

	// 중략..

}

해당 메서드가 구현되어있는 Repository로 가서 살펴보니, 다음과 같이 queryForObject()를 사용하고 있는 것이 문제였다. queryForObject()는 결과가 없으면 null을 반환하는 게 아니라 예외를 던지기 때문에, Service에서 null 체크를 할 수 없던 것이었다!

@Override
public Schedule findScheduleByIdWithPassword(Long scheduleId) {
    return jdbcTemplate.queryForObject(
            "SELECT * FROM schedules WHERE scheduleId = ?",
            scheduleWithPasswordRowMapper(),
            scheduleId
    );
}

따라서 queryForObject() 대신 query()를 사용하여 예외를 발생시키지 않고, 결과가 없으면 null을 반환하도록 수정했다. 그리고 Service에서 null 체크 후 사용자 정의 예외인 ScheduleNotFoundException을 던지는 것에 성공했다.

@Override
public Schedule findScheduleByIdWithPassword(Long scheduleId) {
    String query = "SELECT * FROM schedules WHERE scheduleId = ? AND is_deleted = FALSE";
    List<Schedule> schedules = jdbcTemplate.query(query, scheduleWithPasswordRowMapper(), scheduleId);
    return schedules.isEmpty() ? null : schedules.get(0);
}

Postman에서도 내가 원하는 대 상태코드와 메세지가 출력되는 것을 볼 수 있다.

피드백

✔️ 잘한 점

• 생성 시에는 Created를 delete 시에는 No content와 같이 상태 코드를 적절하게 잘 사용했다.
• 코드 구현 등이 깔끔하게 잘 되어 있다.

✔️ 생각해볼 점

• Repository에서 사용하고 있는 쿼리문을 상수로 정의하면 중복을 줄이고 코드 가독성을 높일 수 있다.
• 각 메소드와 파라미터에 대해 간단한 주석을 추가하면 코드가 더 명확해진다. Java Docs를 검색해 적용해보자!
• findSchedules 메소드에서 AND 1=1 조건을 사용하는 부분이 꼭 필요할까?
• 에러 메세지를 좀 더 구체적으로 작성하면 좋다.
• DB 업데이트와 관련된 모든 작업을 트랜잭션 내에서 처리하는 것이 좋다. @Transactional 및 @Transactional(readOnly=true) 의 차이점을 이해하고 적절하게 사용해보자.

✔️ 궁금했던 점 & 어려웠던 점

• API 명세서를 설계하고 만드는 부분에서 시간 오래 걸렸는데, 어떻게 하면 빠르고 깔끔하게 설계를 할 수 있을까?
  • API는 리소스 중심으로 설계해야 한다. 스케쥴, 유저, 게시물과 같은 리소스들이 정해진다면 각 리소스에 대해 CRUD 작업을 어떻게 할 것인지 정의한다.
  • API 설계를 반복하고, 피드백을 받아 개선하는 연습을 많이 하자.
• 테이블 간 연관관계를 설정하고 서로 연결하는 부분이 어려웠다.
  • ERD를 그려보면서 관계를 시각적으로 이해할 수 있도록 하거나 테이블 간 관계 설정을 먼저 모델링 한 후 이를 엔티티로 구현하는 방식을 사용해보자.
• Service Layer의 수정, 삭제 등의 메서드 내부에서 예외 처리를 했는데, 예외 처리 부분을 따로 빼야할지 고민이었다.
  • 예외를 서비스에서 던지고, 이를 컨트롤러에서 잡아서 적절한 응답으로 반환하는 방식이 좋은 것 같다. 이렇게 되면 나중에 배울 ControllerAdvice를 통해 전역으로 예외 처리를 할 수 있다.
  • 비즈니스 로직과 예외 처리를 분리하고 싶다면, 서비스 레이어에서는 비즈니스 로직만 담당하고 예외처리는 별도의 예외 처리 클래스나 지금 적용 되어있는 @ExceptionHandler에서 담당하게 하는 방식으로 분리를 진행할 수도 있다.
• 예외 처리 시, 모두 Service에서 처리했지만 Repository에서 null을 반환하는 부분도 null을 꼭 반환하게 한 뒤 Service에서 처리를 해야하는 것인지 고민되었다.
  • Repository는 데이터베이스와의 상호작용만 담당하기 때문에 데이터가 존재하지 않으면 null을 반환하거나 빈 리스트를 반환한 뒤, 예외 처리 자체는 서비스 레이어에서 하도록 설계하는 것이 좋다.