✔오늘의 Issue
- 돌연 만들어지지 않는 QClass...그리고 갑자기 다시 만들어짐
- Entity와 Repository, Service 기능 분배에 관한 고민들
- DB 존재 여부에 따라 em.persist 와 em.merge를 따로 나눈 이유 공부 -> 결론: em.merge 하지말고 더티체킹해!
1. 돌연 만들어지지 않는 QClass...그리고 갑자기 다시 만들어짐
QueryDsl 관련해서 빌드 코드들 짜고 그 전까지는 프로젝트에 QClass들이 잘 생성되어 있었고 querydsl도 잘 활용하고 있었다..
그냥 문득 entity에 멤버변수 하나를 추가하고 싶어서 아무 문제없는 멤버 변수 하나 추가했을 뿐인데 다시 빌드해도 QClass에 해당 필드가 반영되지 않았다..
그래서 충돌오류인가 싶어 기존의 QClass를 모두 삭제하고 다시 빌드했더니
빌드가 안됐다,,, QClass 생성이 갑자기 안되는 것이다 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ
빌드 코드를 바꾸지도 않았는데 대체 왜 이러는지 몰라서 한참 헤매고
아무리 구글링해도 나와 같은 사례가 나오지 않았다 대체 왤까
더 웃긴건 일단 무시하고 코드 몇줄 더 짜다가
혹시 몰라서 다시 빌드해봤는데 또 QClass 빌드가 된다(?????????)
마찬가지로 빌드 관련 코드는 건들지도 않았다 대체 웨구레
결론은 아직도 원인을 찾지 못했다..
일단 모르겠으니까 IntelliJ 내부 문제인가 대충 생각하고 있다,,
다음에도 이런 문제가 발생했을때 컴퓨터 재부팅해보고 IntelliJ 재접속해보자
만약 그래서 문제가 해결된다면 이건 진짜 IntelliJ 문제,,
혹은 그래도 안된다면 일단 무시하고 코드 계속 짜고 있어봐....
2.Entity와 Repository, Service 기능 분배에 관한 고민들
내가 JPA에 대한 개념을 완벽하게 빌드하기 보다
그냥 프로젝트로 부딪히면서 배우는게 나을 것 같아서 시작한 토이프로젝트라 그런지 많이 삐걱거리게 된다,,
무작정 JPAShop 프로젝트에서 했던 대로 따라서 Entity 클래스에 생성메서드와 비지니스 로직을 짜려니까 entity 간의 관계가 복잡하게 물려있는 경우는 코드가 상당히 복잡해지고 보기도 어려워졌다.
특히 내가 지금 진행하는 프로젝트의 post- postHashTag - HashTag의 관계가 그랬다 ㅠㅠ
포스트를 작성할 때 유저가 해시태그를 걸면 각 post에 매핑되어있는 postHashTag들이 save 되고 해당 postHashTag중에 HashTag 테이블에 없는 애들은 HashTag에도 save 새로 해주고 이미 있는 애들은 hashTag- postHashTag 매핑만 해주는 로직인데
이걸 Entity에서 짜려니까 머리만 아프고 진행되는게 없었다.
그냥 이런 경우에는 객체지향적 설계에 너무 매몰되지 말고 Service 차원에서 일단은 구현하기로 했다.
👇 요런 식으로
public void save(PostSaveRequest postSaveRequest) {
// 1. Post 저장
Post post = new Post();
post.setTitle(postSaveRequest.getTitle());
post.setContent(postSaveRequest.getContent());
Post savedPost = postsRepository.save(post);
// 2. HashTag 존재하면 기존것을 사용, 없으면 새로 저장
HashTag hashTag = hashTagsRepository.findByTag(postSaveRequest.getHashTag());
if (hashTag == null) {
HashTag newHashTag = new HashTag();
newHashTag.setTag(postSaveRequest.getHashTag());
hashTag = hashTagsRepository.save(newHashTag);
}
// 3. PostHashTag 저장
PostHashTag postHashTag = new PostHashTag();
postHashTag.setPost(savedPost);
postHashTag.setHashTag(hashTag);
postHashTagRepository.save(postHashTag);
}하지만 여전히 객체지향적 설계에 대한 미련은 버리지 못했다.. 객체지향적이면서도 코드진행이 복잡하지 않고 보기에도 좋은 설계가 가능할까? 1차적으로는 Service 차원에서 구현했지만 나중에 유지보수하면서 이 부분을 좀 더 고민해봐야겠다.
3. save 메소드에서 em.persist와 em.merge를 따로하는 이유
이건 갑자기 JPAShop 프로젝트 리뷰하다가
왜 id가 기존에 있으면 update만 해주고 없으면 save 하는지 그게 궁금해져서..
update는 영속성 컨텍스트에 있으면 자동으로 dirty checking 이 되는게 아닌가? 다른 entity는 merge 부분을 따로 구현하지 않았는데
JPAShop 프로젝트에서 item만 이렇게 구현했길래 이유가 궁금해졌다.
(언젠가는 그 이유를 들었었겠지만 금방 까먹은 나레기..)
찾아보니 이거 그냥 em.merge 말고 dirty checking 하라는 예시였다.
DB 업데이트 시 dirty checking 하자~~~
✨오늘의 일기
JPA 하려니까 SpringBoot MVC 부분 다 까먹어서 미치겠다
시간 날때마다 놀지말구 SpringBoot 기본 강의나 돌려봐야지..
그리고 슬슬 Controller 매핑 관련해서 안드로이드 개발을
얼렁뚱땅 UI라도 만들어야겠다,, 라는 생각..... 할 게 많네 ㅎㅎ 파이팅😂
