3:17에 열심히 영속성 주기를 설명해주셨는데, 제가 볼 때는 문제 상황은 영속성과 큰 연관성이 없어서 더 혼란을 일으키는 내용이 아닌가 싶습니다. 문제 상황은 첫 save 때는 db에 이미 존재하지 않아서 isNew가 true가 되고 그 상황에서는 파라미터로 넘긴 entity를 그냥 그대로 리턴합니다. 근데 isNew가 false인 상황에는 merge의 리턴값을 리턴하는데 merge의 리턴 객체는 파라미터로 넘긴 객체와 다른 객체입니다
전 실무에서 save 이후 flush를 자주 사용하고 있습니다 Service 컴포넌트에서 flush 없이 진행하면 uk에 위반되거나 하는게 service를 벗어나고 나서 감지돼서 try catch를 하기 애매하더라구요 그래서 확실히 필요한 부분만 try catch 처리하고 saveAndFlush를 호출하고 있습니다
초반 테스트가 깨지는 예제에서 잘못된 부분이 있는것 같아 의견드립니다. 영속성 상태의 문제가 아니라 두 개의 테스트가 별도의 트랜잭션(혹은 트랜잭션이 없이)에서 동작하기 때문에 발생한 문제라고 생각합니다. 첫 번째 테스트에 의해서 PEPPER 에는 id 가 세팅되어 있는 상태로 두 번째 테스트가 시작된다고 하면, PEPPER 의 id 가 이미 세팅되어 있기 때문에 isNew 는 TRUE 이고, 따라서 save 메소드는 내부적으로 em.merge() 를 호출합니다. (여기까진 동일합니다) 여기서 독립적인 트랜잭션이기 때문에 당연히 1차캐시에는 PEPPER 에 대한 정보가 없습니다. 따라서 그 정보를 채우기 위해 PEPPER 의 id 를 조건으로하는 새로운 select 쿼리문을 날립니다. 그리고 그렇게 조회된 결과를 토대로 현재 트랜잭션의 1차캐시를 채우게되죠. 중요한건 PEPPER 를 1차캐시에 넣는게 아니라 조회된 새로운 데이터로 만들어진 객체를 넣는다는 점입니다. 이후 findById 는 id 를 통한 조회이기 때문에 1차캐시에 있는 정보를 그대로 반환하기 때문에 본 예제에서 crew 와 findCrew 는 동일성을 보장하게 될 것입니다. 하지만 PEPPER 는 그렇지 못한거죠. 그래서 두번째 테스트가 실패하는 것 같습니다.
제가 설명드리겠습니다. 이 ppt에서 다소 헷갈리는 부분이 있습니다. 15:54 에 나오는 compareTo 메서드는, Crew를 비교하는 메서드로, 그 안에 Team::ComapreTo 를 가지고 있습니다. 그리고 17:00 에 나오는 compareTo 메서드는, 그 Team의 compareTo를 보여주는 겁니다. 자 설명을 시작하면, 프록시랑 원래 entity를 잘 이해 하셔야 합니다. 지금 compareTo를 작성하는 위치는 Team 클래스 이므로, 원본 클래스에 작성이 되는겁니다. 즉 이 클래스의 compareTo가 호출되었다는 것은, Team이 생성되었다는 것이고, title을 필드로서 직접 참조할 수 있는겁니다. 근데 인자로 받은 저 Team 의 경우는, 프록시 입니다(Lazy 이기 때문에) 그렇기 때문에, Team 객체가 아닌겁니다. 그래서 getTitle을 호출하면, 프록시가 db를 조회해서, Team 객체를 만들어서, 그 안의 Team.getTitle()을 호출해서, 전달하는 겁니다. 이해가 되셨으면 좋겠습니다.
![[10분 테코톡] 알렉스, 열음의 멀티스레드와 동기화 In Java](http://i.ytimg.com/vi/ktWcieiNzKs/mqdefault.jpg)
![[10분 테코톡] 알렉스, 열음의 멀티스레드와 동기화 In Java](/img/tr.png)
![[10분 테코톡] 바론, 블랙캣의 Querydsl with JPA](http://i.ytimg.com/vi/Dz-46mPfkGo/mqdefault.jpg)
![[2019] Spring JPA의 사실과 오해](/img/n.gif)
삽질일지 정말 흥미진진하네여!!! 이런 공유 너무 좋아요!! 덕분에 많이 배웁니다~! 🙇
이거 라이브로 찐 감명깊게 봤어요 😊
3:17에 열심히 영속성 주기를 설명해주셨는데, 제가 볼 때는 문제 상황은 영속성과 큰 연관성이 없어서 더 혼란을 일으키는 내용이 아닌가 싶습니다. 문제 상황은 첫 save 때는 db에 이미 존재하지 않아서 isNew가 true가 되고 그 상황에서는 파라미터로 넘긴 entity를 그냥 그대로 리턴합니다. 근데 isNew가 false인 상황에는 merge의 리턴값을 리턴하는데 merge의 리턴 객체는 파라미터로 넘긴 객체와 다른 객체입니다
저도 이게 맞는 설명같은데요
발표를 보면 무슨말인지 이해가 더 힘드네요
전 실무에서 save 이후 flush를 자주 사용하고 있습니다
Service 컴포넌트에서 flush 없이 진행하면 uk에 위반되거나 하는게 service를 벗어나고 나서 감지돼서 try catch를 하기 애매하더라구요
그래서 확실히 필요한 부분만 try catch 처리하고 saveAndFlush를 호출하고 있습니다
10:10 좋네요. 지양하는 방법과 지향하는 방법도 알려주시는 내용이라
mybatis만 쓰다가 jpa 입문중인데, 덕분에 영속성의 대한 이해에 보탬이 되었습니다 감사합니다
flush는 jpql이 발생할때가 아니라, 실제 수정내역이 겹치는 id가 있을때 발생하더라구요, 실제로 테스트를 해보시면 더 재밌을것같아요.
좋은강의 감사합니다!
머싯다
초반 테스트가 깨지는 예제에서 잘못된 부분이 있는것 같아 의견드립니다.
영속성 상태의 문제가 아니라 두 개의 테스트가 별도의 트랜잭션(혹은 트랜잭션이 없이)에서 동작하기 때문에 발생한 문제라고 생각합니다.
첫 번째 테스트에 의해서 PEPPER 에는 id 가 세팅되어 있는 상태로 두 번째 테스트가 시작된다고 하면,
PEPPER 의 id 가 이미 세팅되어 있기 때문에 isNew 는 TRUE 이고, 따라서 save 메소드는 내부적으로 em.merge() 를 호출합니다. (여기까진 동일합니다)
여기서 독립적인 트랜잭션이기 때문에 당연히 1차캐시에는 PEPPER 에 대한 정보가 없습니다.
따라서 그 정보를 채우기 위해 PEPPER 의 id 를 조건으로하는 새로운 select 쿼리문을 날립니다. 그리고 그렇게 조회된 결과를 토대로 현재 트랜잭션의 1차캐시를 채우게되죠.
중요한건 PEPPER 를 1차캐시에 넣는게 아니라 조회된 새로운 데이터로 만들어진 객체를 넣는다는 점입니다.
이후 findById 는 id 를 통한 조회이기 때문에 1차캐시에 있는 정보를 그대로 반환하기 때문에 본 예제에서 crew 와 findCrew 는 동일성을 보장하게 될 것입니다.
하지만 PEPPER 는 그렇지 못한거죠. 그래서 두번째 테스트가 실패하는 것 같습니다.
PEPPER 의 id 가 이미 세팅되어 있기 때문에 isNew 는 TRUE 이고 --> FALSE 를 잘못 말씀하신거죠?
저런 발표자료는 ppt로 만드는건가요?
코드 가독성이...
모라는지 모르겠다..
17:00 에 앞의 title은 getTitle() 부를 필요가 없다는건 납득이 안되네요. 설명해주실 전문가 분들 있습니까?
제가 설명드리겠습니다.
이 ppt에서 다소 헷갈리는 부분이 있습니다. 15:54 에 나오는 compareTo 메서드는, Crew를 비교하는 메서드로, 그 안에 Team::ComapreTo 를 가지고 있습니다.
그리고 17:00 에 나오는 compareTo 메서드는, 그 Team의 compareTo를 보여주는 겁니다.
자 설명을 시작하면, 프록시랑 원래 entity를 잘 이해 하셔야 합니다.
지금 compareTo를 작성하는 위치는 Team 클래스 이므로, 원본 클래스에 작성이 되는겁니다.
즉 이 클래스의 compareTo가 호출되었다는 것은, Team이 생성되었다는 것이고, title을 필드로서 직접 참조할 수 있는겁니다.
근데 인자로 받은 저 Team 의 경우는, 프록시 입니다(Lazy 이기 때문에)
그렇기 때문에, Team 객체가 아닌겁니다. 그래서 getTitle을 호출하면, 프록시가 db를 조회해서, Team 객체를 만들어서, 그 안의 Team.getTitle()을 호출해서, 전달하는 겁니다.
이해가 되셨으면 좋겠습니다.