Board를 사용하고 있지만 , Member을 같이 조회해야 하는 상황이다. Board클래스에는 Memeber와의 연관관계를 맺고 있으므로 b.wirter와 같은 형태로 사용한다.
내부에 있는 엔티티를 이용할 때는 'LEFT JOIN' 뒤에 'on'을 이용하는 부분이 없다.
- on을 사용하지 않는다.
- 대신에 FK값으로(교집합) 으로 조인 해준다.
Board 와 reply 의 경우 Board입장에서는 Reply 객체들을 참조하고 있지 않다. 이럴때는 on 을 사용한다.
목록 화면에서는 게시글/작성자/댓글개수 만 나오게 만들어 봤다.
첫번째 문장은 Board와 member를 조인해서 만든 테이블이고
두번째 문장은 Board 와 Reply 를 조인해서 만든 테이블이다
세번째 문장은 셋다 합친 테이블이다. 하나의 게시물당 하나의 라인이 될수 있도록 group by를 사용했다.
4. 목록(list) 쪽과 pageable(페이징,정렬은) 세트인걸 기억하자
보통 SQL문과 비슷해 자세한 설명은 생략 한다.
pageable(기본페이징, 정렬) 이 매개변수이면 반환타입은 page<>이다
쿼리메서드의 경우에는 엔티티 타입의 데이터만을 추출하지만 @Query는 현재 필요한 데이터만을 Object[]의 형태로 추출한다.
조회 화면에서는 목록과 비슷하게 게시물/작성자/댓글개수 로 만들 예정이여서 앞에서 사용한 JPQL을 게시물 번호만 받을수 있도록 수정 했다.
앞에서 조회화면을 만들떄 해당 게시물 번호(gno)를 눌렀을떄 조회 페이지로 들어가도록 만들었다.
BoardDTO클래스가 Board 엔티티 클래스와 다른점은 Member를 참조하는 대신에 화면에서 필요한 작성자의 이메일과 작성자의 이름 으로 처리 하고 있다는 점이다.
DTO 와 Entity는 항상 같을수는 없다.
목록화면에서 BoardDTO를 이용하기 때문에 replyCount도 넣어준다.
게시물 등록은 BoardDTO 로 전달 받고 JPA를 사용하기 위해 Entity 타입으로 변환한다.
dtoToEntity 는 DTO가 연관 관계를 가진 Board엔티티 객체와 Member 엔티티 객체를 구성해야하므로 내부적으로 Member 엔티티를 처리하는 과정을 거쳐야한다.(이떄 Member은 실제 DB에있는 이메일 주소로 한다)
Objectp[] 을 DTO로 변환하기
다소 복잡해 보이지만 한줄씩 해석하면 된다.
result부분은 @Query 로 받은 결과(테이블)를 (페이징,정렬) 처리를 해준값이다.
function 부분은 엔티티들을 dto로 변환해 주는 기능이다.
repositoy에 JPQL로 구현해 놓은 매서드를 이용해 get()를 만들어준다.
화면에 뿌려주기위해 Entity->DTO변환도 잊지말자
게시물을 삭제할때 댓글까지 지워버리므로 동의 없이 댓글을 지우면 문제가 발생한다.
여기서는 댓글부터 먼저지우고 게시물을 지우는 형식으로 만든다.
댓글이 삭제되고 게시물을 삭제한느중 오류가나 한쪽만 삭제되는 문제를 방지하기위해 @Transactional 처리를 반드시 해준다.
(reply repository에 JPQL 쿼리문 을 만들어준다)
댓글부터 삭제하고 게시물을 삭제해준다.
reply repository를 @Autowired해준다.
-수정은 필요한 부분만 변경하고 BoardRepository의 save()를 이용해서 처리한다.
changeTitle() , changeContent() 를 추가해준다.
클라이언트가 수정할 DTO를 보내면 그DTO의 게시물번호(gno) 를 통해 db의 원본 파일을 조회한다.
원본파일에 메서드를 이용해 수정된 부분을 적용한다.