둘셋 개발!

엔티티 (JPA가 관리하는 객체)의 기본키를 자동으로 생성하는 전략에는 3가지가 있다. 1. IDENTITY 2. SEQUENCE 3. TABLE 아래의 내용은 각각의 전략에 대한 설명과 성능향상을 위한 방법과 실제 사용 예시이다. 1. IDENTITY @Entity public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; //... } 이 전략은 기본키 생성을 DB에게 위임하는 것이다. 엔티티를 영속성 컨텍스트에 persist 하려고 할 때 DB에 저장하고 DB로부터 기본키를 받아 영속성 컨텍스트에 저장한다. 원래는 새로운 엔티티를 영속화하면 insert 쿼리를 쓰기 지연 SQL에 저장하고,..

전체적으로 다음그림과 같이 Jpa가 동작한다 1. 설정 정보 조회 ✔️Persistence라는 클래스가 persistence.xml에 있는 설정정보를 조회한다 다음은 persistence.xml 예시이다 ➡️ 데이터베이스에 연결하기 위한 설정이 바로 여기에 있다 ➡️ 특정 데이터베이스만의 고유한 기능을 jpa 에서는 방언이라고 하는데 방언을 여기서 지정해준다. 즉, jpa는 특정 데이터베이스에 종속적이지 않는다. 2. EntityManagerFactory 생성 ✔️persistence.xml의 설정정보를 조회하고 이를 토대로 엔티티매니저 팩토리(emf 라고 줄여서 쓰겠다..)를 생성한다. ✔️emf는 딱 하나만 생성해서 애플리케이션 전체에서 공유한다 - persistence.xml 설정정보를 읽어서 jp..

컬렉션인 일대다 관계를 조회하고, 최적화 하는 방법이다. 일대다 관계이기 때문에 데이터가 배로 커지기 때문에 문제가 발생하고, 또한 중복도 발생한다 1. 엔티티 조회방식 SQL에 distinct를 추가해서 같은 엔티티가 조회되면, 애플리케이션에서 중복을 걸러준다. 하지만 이에 치명적인 단점은 페이징이 불가능하다는 것이다. 애플리케이션에서는 Order의 id가 같으면 중복을 제거 해주지만, 데이터베이스에서는 한 줄에 있는 모든 데이터가 같아야 중복이 되기 때문에 데이터가 배가 되는 문제는 피할 수가 없다. 따라서 원하는대로 페이징을 할 수 없다. 해결방법은 hibernate.default_batch_fetch_size, @BathSize를 적용하는 것이다. 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한..

주문 객체는 회원과 배송정보가 함께 있기 때문에 이때 발생하는 이슈들을 잘 다뤄봐야 한다. order객체 mem와 address는 지연로딩으로 설정되어 있기 때문에 order를 불러올 때 이 둘은 프록시 객체가 있다. 그래서 json은 이를 프록시 객체를 어떻게 생성하지 모르기 때문에 Hibernate5Module을 스프링 빈으로 등록시킴. 이렇게 되면 지연로딩은 null로 처리되고 정상적으로 돌아간다. 하지만 엔티티를 외부에 그대로 노출시키는 것은 좋지 않다. 그래서 해결방법은 DTO를 생성하는 것이다. 하지만 이때 성능문제가 발생한다. order.getMember().getName() 과 order.getDelivery().getAddress() 를 할 때 지연로딩이 초기화 된다. 그러면 name과 ..