만들자 게시판 4주차 (1) - 첨부파일 삭제 API 구현

결국 이번에도 늦어버렸다. 언제쯤이면 바쁘다는 구차한 핑계로 스스로 정당화하지 않을수 있을까..

반성 또 반성한다.

그치만 바쁜걸 이잉

 

업로드, 다운로드에 이어 삭제. 파일은 디스크와 DB 두 곳 모두에 흔적이 남아서 삭제도 두 곳 다 지워야 완전하다.

 

순서가 왜 중요한가?
두 작업을 순서대로 실행하다가 중간에 하나가 실패하면 어떻게 될까.

1. 디스크 먼저 지우고 DB가 실패하면 → DB엔 있는데 실물이 없는 "유령 파일" (목록엔 뜨는데 다운로드하면 에러)

2. DB 먼저 지우고 디스크가 실패하면 → 실물은 있는데 DB엔 없는 "고아 파일" (아무도 못 찾지만 용량만 차지)

둘 다 완벽하진 않은데, 고아 파일 쪽이 낫다고 판단했다. 조용히 방치돼도 사용자는 아무 문제를 못 느끼지만, 유령 파일은 사용자가 클릭했다가 대놓고 에러를 만나기 때문이다. 그래서 DB 먼저, 디스크 나중 순서로 정했다.

 

// FileService.java
public void deleteFile(Integer id) throws IOException {
  FileEntity file = fileRepository.selectFileById(id);
  Path filePath = Paths.get(file.getFilePath()).resolve(file.getStoredName());
  fileRepository.deleteFile(id);
  Files.deleteIfExists(filePath);
}

 

Files.delete 대신 Files.deleteIfExists를 쓴 이유도 있다. delete는 파일이 이미 없으면 예외를 던지는데, deleteIfExists는 없으면 조용히 false만 반환한다. 나중에 다른 기능(게시글 삭제 시 첨부파일 정리 등)에서 이 메서드를 재사용할 때, 이미 지워진 파일을 또 지우려는 상황이 생길 수 있어서 더 안전한 쪽을 골랐다.

 

사실 삭제는 크게 어려운 구현은 아니었다.

 

삽질 기록
처음엔 Files.deleteIfExists(filePath) (디스크 먼저)를 위에, fileRepository.deleteFile(id) (DB 나중)를 아래에 써서 순서를 거꾸로 짰었다. 

순서를 이미 정해놨는데 코드는 반대로 짠거다.. DB와 디스크 중 뭘 먼저 지울지 결정하는 것과 그 결정대로 코드를 쓰는 것은 다른 문제라는 걸 깨달았다.