솔직히 이번 파트가 제일 오래 걸린거 같다쿼리에 익숙하지 않아서인지 한줄 한줄 해석하는데 시간이 오래 걸렸다.요구사항을 보면1. 제목/작성자/내용 텍스트 검색 2. 카테고리 필터 3. 등록일 검색, 디폴트 최근 1년 4. 페이징 (10개씩, 총 건수) 5. 목록에 첨부파일 유무 표시이렇게 되있었다. 동적 SQL을 사용했는데, 조건이 있을 수도 있고 없을수도 있으니, SQL을 상황에 따라 조립해야 했다.//"selectBoardList라는 이름의 SQL이고, 실행 결과 각 행을 BoardEntity 객체에 담아라"는 선언.//board 테이블(별명 b)에서 가져올 컬럼들 나열. BoardEntity의 필드 이름과 매칭돼서 자동으로 채워짐. SELECT b.id, b.category_id, b.title,..
게시판 만들기 요구사항을 보면 서버 측 유효성 검증 조건이 있었다.작성자 3~4자, 비밀번호 4~15자(영문/숫자/특수문자 포함), 제목 4~99자, 내용 4~1999자, 카테고리 필수 어떻게 유효성 검증을하지?Spring이 제공하는 spring-boot-starter-validation을 쓰면, DTO 필드 위에 애노테이션만 붙여서 검증 규칙을 선언할 수 있다.// build.gradleimplementation 'org.springframework.boot:spring-boot-starter-validation'gradle에 넣고 싱크 돌려주면 사용이 가능하다! 어떻게 사용하지?다양한 어노테이션을 지원하는데 대표적으로 @Size, @Pattern, @Min, @Max, @Email 등이 있다 // B..
결국 이번에도 늦어버렸다. 언제쯤이면 바쁘다는 구차한 핑계로 스스로 정당화하지 않을수 있을까..반성 또 반성한다.그치만 바쁜걸 이잉 업로드, 다운로드에 이어 삭제. 파일은 디스크와 DB 두 곳 모두에 흔적이 남아서 삭제도 두 곳 다 지워야 완전하다. 순서가 왜 중요한가?두 작업을 순서대로 실행하다가 중간에 하나가 실패하면 어떻게 될까. 1. 디스크 먼저 지우고 DB가 실패하면 → DB엔 있는데 실물이 없는 "유령 파일" (목록엔 뜨는데 다운로드하면 에러)2. DB 먼저 지우고 디스크가 실패하면 → 실물은 있는데 DB엔 없는 "고아 파일" (아무도 못 찾지만 용량만 차지)둘 다 완벽하진 않은데, 고아 파일 쪽이 낫다고 판단했다. 조용히 방치돼도 사용자는 아무 문제를 못 느끼지만, 유령 파일은 사용자가 클..