앞서 많은 분들이 질문하셨지만, 아직 명확하게 이해가 되지 않아서 질문드립니다. 10분 40초 부분의 getReference() 조회 시, Id 값은 이미 있기 때문에 쿼리가 날아가지 않는다는 것에 대한 의문입니다. 우선, 의문이 들었던 지점입니다. Member 엔티티의 Id를 GeneratedValue 방식 사용하는 상황에서, 1 em . persist ( member ) ; 2 3 em . flush (); 4 em . clear (); 5 6 em . getReference ( Member . class , member . getId ()); 7 8 System . out . println ( "findMember.id = " + findMember . getId ()); 위와 같은 코드를 실행했을 때 상황입니다. 1) 제가 이해한 위 코드 실행시 발생하는 일을 순서대로 정리해보면: 1행: em.persist(member); (1) DB의 전략에 따라 DB에서 ID값을 generate하고, (2) 생성된 ID값이 1차캐시의 key로 저장된다. 4행: em.clear(); (1)영속성 컨텍스트가 완전히 비워진다: 즉 1차 캐시에 저장된 Id값도 비워진다. 6행: em.getReference(Member.class, member.getId()); (1)1차캐시에서 id값을 찾음 (2)4행의 (1)로 인해서 캐시에서 Id 값을 찾을 수 없기에 DB에 SELECT 쿼리를 던지게 된다. 2) 때문에 "Id값이 이미 있기 때문에 INSERT 쿼리가 날아가지 않는다"는 것이 이해가 되지 않습니다. 구체적으로 궁금한 것은 (1) 위에서 말하는 저장된 id값이 어떻게 저장되었냐는 것입니다. (2) id값이 이렇게 저장되는 것은 어느 시점에서 이루어졌냐는 것입니다. 두 문제에 대한 제 생각은 (1) 영속성 컨텍스트에 저장된 것이 아니고, member 인스턴스의 변수 member.id가 다른 인스턴스 변수들처럼 관리되어서 저장된 것이다. (즉 우리가 비영속 상태의 인스턴스 book에 book.setName("Jpa")하는 식으로 값을 저장할 때처럼 저장되는 것이다) (2) 1행의 (2), 즉 1차캐시의 key로 저장되는 시점에 저장되었다. 인데, 이 이해가 적절한 것인지 궁금합니다. 즉, <영속화되는 엔티티의 id값은 DB에서 생성되어, 1차캐시에 저장되는 시점에 인스턴스 변수에 저장된다.> 그리고 <그 id값은 해당 인스턴스와 동일한 생명 주기를 갖는다>가 적절한 이해인지 궁금합니다.
정말 부끄러운 질문일수도 있겠지만 궁금한건 알고싶어서 이렇게 질문 남깁니다(야생형 코스 밟으면서 진행하고있습니다) 저번 강의때 db가 꺼져있어도 local db? 로 테스트를 진행할 수 있다고 들었던거 같은데 저는 테스트를 돌릴때 db가 꺼져있으면 쿼리가 제대로 올라오지 않고 테스트에서 IllegalStateException이 뜨게 되는데 혹시 저의 미천한 궁금증을 해결해주실수 있을까요? 아니면 원래 개발할때는 db서버를 상시 열어두는게 기본중에 기본인가요...?
안녕하십니까 강사님 객체지향에 대해 궁금한 점이 생겨 질문드립니다. 17:05에서 order라는 메서드 안에 createOrderItem, createOrder 메서드들이 있습니다. 이 두 메서드는 OrderService 입장에서 OrderItem과 Order한테 "니네가 무슨 일은 하는지는 모르겠지만, 나는 이 두 개를 받아서 주문을 생성한다"라는 말이잖아요? OrderService가 하는 일은 OrderItem과 Order에서 받은 것들을 이용하여 주문 생성 OrderItem이 하는 일은 주문 상품 생성 Order가 하는 일은 주문 생성 그렇다면 이게 객체지향성을 나타내는 것일까요? 감사합니다
안녕하세요 강사님! 강사님의 강의 영상을 보고 Spring Data JPA 를 학습했던 학생입니다. 다름이 아니라 데이터베이스 설계 시에 다음과 같은 상황에서는 어떤 방법이 일반적인지 실무의 관점에서 조언을 얻고자 합니다. `USER`, `COURSE`, `ASSIGNMENT`, `ASSIGNMENT_SUBMIT` 이렇게 4개의 테이블이 있다고 가정할 때, USER : 사용자 테이블 COURSE : 강의 테이블 ASSIGNMENT : 과제 테이블 ASSIGNMENT_SUBMIT : 학생이 제출한 과제 테이블 ASSIGNMENT_SUBMIT 테이블의 PK가 어떤 형태로 되어야 하는지 각각의 장단점에 대해 생각을 해보았습니다. 1. id 라는 칼럼을 만들어서 Auto_Increment 로 pk 를 관리한다. - 장점 - findById 에서 숫자 인덱스를 이용한 조회를 하기 때문에 조회 속도가 빠르다. - 단점 - 칼럼 하나가 늘어난다. 2. user_id 와 assignment_id 라는 두 개의 칼럼을 이용해서 pk로 관리한다. - 장점 - id 칼럼이 사라진다. - 단점 - jpa 에서 제공하는 기본 findById 가 사라진다. - fk 를 결합하여 pk 를 만드는 레퍼런스를 찾지 못했다.. 정도 있습니다. 만약 강사님이시라면 어떤 선택을 하실지 또한 각각 어떤 장단점이 더 있을지 알려주실 수 있으실까요?
4:33에 order 하나 만들었는데 #3이 되어있어서 확인해보니까 멤버 하나 만들면member_id=1 아이템 하나 만들면 item_id=2 주문 하나 만들면 order_id=3 이런식으로 id가 공유되는거 같은데 @GeneratedValue 때문인가요? 각각 따로 id를 만들어줄려면 어떻게 해야하나요?
안녕하세요 영한님 저는 jpa 야생형 로드맵을 수강한 후 토이프로젝트를 진행하고 있는 도중 여쭈어보고 싶은게 생겨서 글을 올리게 되었습니다. 먼저 해당 강의를 통하여 내부조인을 사용하면, where 절에서 필터링 하는 것과 기능이 동일하기 때문에 where절의 의도와 맞게 내부조인에서는 on절이 아닌 where절을 사용하는게 좋다고 이해하였습니다. 아래 사진은 파라미터가 Item의 name에 포함된 경우 해당 Item의 관련된 여러 테이블을 join하여 Shop을 조회하고 싶어서 작성하게 된 코드와 실행했을 때 나타난 쿼리입니다. 처음에는 findByNameContainsV1 메소드를 작성하였지만 Item부터 Shop 사이에 있는 모든 테이블을 조인한 후 where절에서 Item의 name과 같은 Shop을 조회하기 때문에 조금 더 쿼리를 최적화 시킬 수 있다고 생각했습니다. 그래서 findByNameContainsV2 메소드를 작성하게 되었는데요. sql 문법상 join이 where보다 먼저 실행된다고 알고 있었기 때문에 where 대신 on절을 넣어주었습니다. 하지만 테스트를 통하여 on절에도 동적쿼리를 사용할 수 있는지 확인해 보았지만 불가능했습니다. 아직 개발에 대한 지식이 많이 부족해서 성능 최적화에 대해 잘 모르지만 저는 findByNameContainsV2 메소드가 findByNameContainsV1메소드보다 더 성능이 잘 나온다고 생각이 되지만 QueryDSL은 JPA에서 동적 쿼리를 사용하기 위해 실무에서 도입하게 된 것이므로 굳이 고민하지 않아도 되는 것인지, 아니면 실무에서 동적쿼리가 아닌 경우에 findByNameContainsV2 메소드와 같이 코드를 작성해도 되는지 영한님의 의견을 여쭈어 보고 싶습니다.
Junit5와 Junit4 에서의 회원가입테스트에서 Junit5는 Long savedId = memberService.join(member); 에서 NullPoniterException이 터지게 되는데 Junit4에서는 정상적으로 테스트가 완료됩니다. 야생형코스로 하고있는데 이러한 테스트 결과에서 도저히 이해가 안되서 이렇게 질문 남깁니다...
스승님 그간 평안하셨는지요,, 다름이 아니라 불초의 제자 질문이 있어 이 야심한 시간에 편지 올립니다. WAS를 한대만 운용한다는 가정하에 사용자의 접속 세션 허용범위를 2개로 주었어요, 웹으로 접속함과 동시에 모바일에서도 접속이 가능하게 만들어 주었다고 생각해 보았습니다. 전에 아래와 같은 말씀을 해주셨는데 ---------------------------- 서버가 한대만 있고, 자바(JVM)로 웹 애플리케이션을 단 하나만 구동하는 상황이면 자바 만으로 동시성 제어를 할 수 있습니다. 그런데 실무에서는 보통 서버 두 대 이상을 사용하기 때문에, 동시성 제어를 JVM안에서 해결하는게 어렵습니다. 관계형 데이터베이스는 이런 동시성 제어를 고려해서 개발되었기 때문에, 결국 관계형 데이터베이스에 동시성 제어를 위임해야 합니다. 그 중에 관계형 데이터베이스가 제공하는 유니크 제약조건을 사용하면, 같은 이름을 절대로 동시에 저장할 수 없습니다. 그래서 name에 유니크 제약조건을 실무에서는 걸어주어야 한다고 이야기 했습니다. 그런데 이런 유니크 제약조건은 정말 최악의 경우(진짜 초 단위로 같은 데이터가 저장되었을 때)가 발생했을 때 동작하는 것이고, 대부분은 validation에서 막힙니다. ----------------------------- 위에서 제가 가정한 상황에서 사용자가 웹이랑 모바일에서 동시에 요청을 보냈는데 그게 하필 동시성 문제를 일으킨다면 이런 상황에서도 데이터베이스 lock을 안걸고 자바만으로 동시성을 제어할 수 있는 방법이 있을까요?? (혹은 세션이 2개가 아니더라도 1개의 세션에 1 명의 사용자가 동시에 같은 요청을 보낼 경우에두요!,, 너무 여러개 번거로운 질문 죄송합니다 ,, ㅠㅠ)
안녕하세요. 질문은 2가지 정도가 있는데 다음과 같습니다 1. DTO를 반환하는 형태의 JPQL를 작성할 때 join문을 사용해서 쿼리를 작성해주셨습니다. 문득 로그를 보다가 든 생각이 DTO가 아니라 entity를 조회하기 위해 JPQL을 작성할 때, join을 사용하면 즉시로딩이나 지연로딩 관계없이 연관객체에 대해서 N+1문제가 발생하는 걸로 알고 있습니다. 근데 DTO를 반환하는 형태로 JPQL를 작성할 때는 join문을 사용해도 쿼리 한번에 연관객체들의 정보를 가져오더라구요 (강의에서 Order의 Member나 Delivery) 이러한 차이의 이유가 JPQL이 실행 될 때 JPA에서 관리를 하냐 안하냐의 차이로 볼 수 있을까요? 2. JPA는 트랙잭션 안에서만 동작한다고 알고 있습니다. 그런데 강의를 보다보면 Controller에서 Repository를 바로 의존성 주입받아서 사용하시더라구요. @Transaction은 서비스에만 붙어있고 Repository에는 선언되어 있지 않은데 정상적으로 동작하는 것은 조회는 트랙잭션 관계없이 JPA에서 사용이 가능한것인가요? 그 서비스 코드를 작성할 때 조회 메서드는 readOnly속성을 true로 주면서 작성했던 걸 보면 조회할 때도 @Transaction이 선언되어야 동작하는것이 아닌가 하는 생각이 들어서 질문 남겨드립니다. 항상 명강의 해주셔서 감사합니다. ps. MSA와 관련한 강의는 계획이 없으신가요? ㅎㅎ
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 관련 질문: https://www.inflearn.com/questions/216545 추가 내용이 있습니다. 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] Collection type으로 Set 대신 List를 사용하시는 이유가 궁금합니다. 지금까지 나온 Collection들이 모두 unique한 Entity(또는 값 타입)들의 collection이기 때문에, Set을 활용할 경우 중복 확인 관련 부분이 깔끔해지고, 다른 질문의 답변에서 답해주신대로 값 타입 컬렉션에도 row를 모두 날리고 다시 넣는 문제를 막을 수 있어 Set에 대해 좋은 인상을 가지게 되었습니다. 그런데 기본적으로 예제가 List를 사용하여, Set을 사용하였을 때 제가 놓친 문제가 있는지 의문이 들었습니다.
"select m . team from Member m " ; 위의 쿼리문을 명시적 조인으로 바꾸면 "select t from Member m join m . team t " ; 이렇게 바꾸는 게 맞을까요?? 찍어보니까 쿼리는 같은 쿼리가 나옵니다! 영한님이 말씀하시건 결국 전부 풀어서 쓰라는 말이 맞을까요?
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] MemberTest 코드에서 EntityManager를 @PersistenceContext 를 통해 주입받으셨는데 @Autowired 로 주입을 받아도 정상적으로 작동하더라고요. 찾아보니 @PersistenceContext 를 통해 EntityManagerFactory에서 주입받기 위해서다, 여러 요청에 대하여 동일한 EntityManager를 반환하기 위해서이다. 라는 말을 들었는데 위의 이유들 때문인가요? @Autowired vs @PersistenceContext 의 차이를 알고싶습니다.
영한님께서 설명해주신 내용중 연관관계 편의메소드 등에서 Setter로 인한 문제점들은 알겠습니다. 이를 해결하기 위한 방법중 연관관계 편의 메소드에서 setXXX() 등을 사용하기 보단 별도의 메소드를 생성하여 changeMember()등으로 사용하는 것은 괜찮은지 궁금합니다. 예를들어 아래와 같이 작성시 문제가 될 소지가 있는지...궁금합니다. public void changeOrder (Order order) { this . order = order ; } //===연관관계 편의 메서드 ===// public void addOrderItem (OrderItem orderItem) { this . orderItems .add(orderItem) ; orderItem.changeOrder( this ) ;
