매핑 하기 전 리팩토링 먼저하자
findAll을 우리가 만든게 아니다
인터페이스에서 implement한 JpaReqository<Board, Integer> 안에 기본 것들이 다 들어가 있다
Pageable pg = PageRequest.of(0, 3, Sort.Direction.DESC, “id); 이거는 페이징하는 건데 나중에 하자
Sort sort = Sort.by(Sort.Direction.DESC, “id”); 게시글 순서 54321 이렇게 만드려고 함
만약 jpa쿼리 말고 내가 쿼리짜서 하고 싶다면 아래 Sort말고 다른 걸로 하고 싶으면 제목을 찾아보자
boardRepository이동
삭제(둘 다)
boardService이동
바꾸기 find
윗 코드는 풀어쓰면
Optional<Board> boardOP = boardRepository.findById(1);
if(boardOP.isEmpty()){
throw new Exception404("게시글을 찾을 수 없습니다");
}
Board board = boardOP.get();변경하자
boardRepository
트랜잭션 필요 없어서 지웠는데 delete도 이미 있으니 지워라
보드 서비스 이동
변경
굳이 sort모르면 안 써도 괜찮음 내가 만들면 되니까
이렇게
유저 서비스
기존 코드
유저 이름으로 존재하는지 확인하는 것
User userPs = userRepository.findByUsername(joinDTO.getUsername())
null이 아닐 때 이미 존재 하는 유저 라고 하는건데
내가 null을 안 넣을 수 도 있으니 바꿔야 한다!
if(userPs ! = null){
throw new Exception400(”이미 존재하는 유저입니다.”);
}
유저 리포지토리
바꾸면 무조건 없으면 null이어서
바꾸자
User → Optional<User>로
→
리팩토링
이거는 .orElseThrow하면 안됨
못 찾은 거는 예외가 아니니까!!
두 개 변경
연습하기
optional 연습다시
유저 서비스로
원래는 인터페이스를 넣어 왔는데 이제는 람다식을 넣을 수 있다
오류
수정
내가 적은 글이 아닐 때 터지면 안됨
또 오류
디테일머스테치 변경
상세보기 하면 select 2번 날라간다
id찾았는데 detail머스테치 할때 또 해서
findById를 내가 만든게 아니니까 예전에는 join했어서
쿼리도 확인해야 한다!!!
해결
보드 레파지토리로 변경
jpa에 findById가 있는데
join해서 들고 왔어요 lazy로딩해서 들고왔어요?
join하고 들고 왔다고 하겠지 그러면
findById는 언제 필요할까?
mFindById만 필요할까?
언제 findById를 쓰냐?
게시글 수정할 때 존재하는 지 확인하려고
게시글 삭제할 때 존재하는지 확인하려고
과연 이 두개가 join이 필요할까?
필요 없다!!
무조건 findById가 필요하다!!! join하면 낭비니까!!
게시글 삭제 찾는 이유가 뭔데? 유효성 체크 하고
드라이빙, 드리븐 테이블 있을 때 앤포드라 했으니까 드라이빙테이들이 포린키
a방에 있는데 다같이 있다 와이프도 있고
옆 방에 자식들이 1명씩 있어
찾으면 끝인데
애기 입장에서 한명씩 와서 내 아빤가? 아이네 맞다면 엄마도 찾아야 해서 계속 찾아야 한다!!
북한에서 우리나라 김씨를 찾고 싶어 찾을 수 는 있는데 엄청 오래 걸림
주민 번호로 찾으면 금방 찾는다
유일하지 않는 것을 빠르게 찾는 법은 모아두는 것이다!
만약 우리나라 경기도에 김씨 다 모아두면 서울 찾고 경기도에서만 찾으면 끝난다
데이터 서치는 무조건 오래 걸리기 때문에 내가 찾을 데이터가 빠르게 찾을 수 잇게 정렬돼있던가 유일하던가 해야 한다
join은 나와 옆 테이블 for문 돌리며 계속 찾는다.
on절
엄청 오래 걸린다!! 이것 보다 더 오래 걸리는게 select 2번 하는 거다!! io두번 돌리기 때문에
for문이 아무리 느리다 해도 io보다 느릴 수 없다!!
select두번은? 가독성이 좋아질 때가 있다
join하는 것 보다 select하는게 더 좋을 때가 있다. 빠른게 다 좋은 것은 아니다.!
Share article
