JPQL (Java Persistence Query Language) 객체지향 쿼리 언어이기 때문에 테이블을 대상으로 쿼리 하는 것이 아니라 엔티티 객체를 대상으로 쿼리 한다. JPQL은 SQL을 추상화해서 특정 데이터베이스 SQL에 의존하지 않는다. JPQL은 결국 SQL로 변환된다. select_문 :: = select m from Member as m [where_절] [groupby_절] [having_절] [orderby_절] update_문 :: = update m [where_절] delete_문 :: = delete m [where_절] 엔티티와 속성은 대소문자를 구문하고 JPQL 키워드는 대소문자를 구분하지 않는다. 테이블의 이름이 아닌 엔티티의 이름을 사용하고 별칭(m)은 필수로 사용한..
JPA는 다양한 쿼리 방법을 지원한다. JPQL (대부분 이 방식을 사용) JPA Criteria QueryDSL 네이티브 SQL JDBC API 직접사용, MyBatis, SpringJdbcTemplate 함께 사용 JPQL 가장 단순한 조회 방법 EntityManager.find() 객체 그래프 탐색 a.get() 기타 등등 ... 하지만 특별한 조건을 포함한 데이터를 알고 싶다면? EntityManagerFactory emf = Persistence.createEntityManagerFactory("Test"); EntityManager em = emf.createEntityManager(); EntityTransaction tx = em.getTransaction(); tx.begin(); try..
JPA 데이터 타입 분류 엔티티 타입 @Entity로 정의하는 객체 데이터가 변해도 식별자로 지속해서 추적이 가능하다. 값 타입 int, Integer, String 처럼 단순 값으로 사용하는 자바 기본 타입이나 객체. 식별자가 없고 값만 있으므로 변경시 추적이 불가능하다. 값 타입 분류 1. 기본값 타입 자바 기본타입(int, double) 래퍼 클래스(Integer, Long) String → 생명주기는 엔티티에 의존한다. 값 타입은 공유하면 안된다. (다른 저장공간을 갖는다) 2. 임베디드 타입 (복합 값 타입) 새로운 값 타입을 직접 정의할 수 있음 JPA는 임베디드 타입(embedded type) 이라고 부른다 int와 String 처럼 값 타입이라는 것이다. → 변경하면 끝 3. 컬렉션 값 타..
JPA에서 가장 중요한 2가지 객체와 관계형 데이터 베이스 매핑 (Object Relational Mapping)영속성 컨텍스트웹 어플리케이션 개발시 EntityManager Factory가 고객의 요청에 따라서 EntityManager 를 생성하고 EntityManager를 통해서 데이터를 관리하게 된다. 영속성 컨텍스트 엔티티를 영구 저장하는 환경 : EntityManager.persist(entity); (눈에 보이는 개념은 아니다) 엔티티의 생명주기비영속(new/transient): 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태영속(managed): 영속성 컨텍스트에 관리되는 상태준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태삭제(removed): 삭제된 상태 ◆ 비영속 ..
프로그램 실행 모습 메인 홈페이지는 회원 기능과 상품 기능 그리고 주문 기능으로 구별지어 총 6가지의 기능을 제공한다. 회원가입 기능을 통해 위와 같은 정보를 입력한 후 submint을 통해 데이터를 넘겨주면 아래과 같은 회원의 상태를 볼 수 있다. 주의 할 점은 이름을 입력하지 않은 회원은 가입이 불가능하도록 설정했기 때문에 회원의 이름은 필수 입력사항이다. 다음은 상품 등록 기능이다. 백과사전이라는 상품을 6개 등록하고 수정 기능을 통해 상품의 수량을 3개로 수정했다. 상품을 주문을 하고 나면 아래와 같은 주문 내역을 확인할 수 있다. 주문의 상태는 ORDER 상태이고 주문 취소를 의미하는 cancel 버튼을 클릭하면 아래와 같이 주문의 상태가 CANCEL로 바뀌는 것을 알 수 있다. 깃허브 주소 :..
준영속 엔티티를 수정하는 2가지 방법준영속 엔티티: 영속성 컨텍스트가 더는 관리하지 않는 엔티티를 의미. 변경 감지 기능 사용(Dirty Checking)트랜잭션 안에서 엔티티를 다시 조회, 변경할 값 선택하고 수정한다. 이후 트랜잭션 commit 시점에 변경 감지 기능(Dirty Checking)이 동작해서 JPA가 자동으로 데이터 베이스에 UPDATE 쿼리를 날려준다. 병합(merge) 사용merge 함수 호출을 통해 값을 변경: 준영속 엔티티의 식별자 값으로 영속 엔티티를 조회한후 영속 엔티티의 값을 준영속 엔티티의 값으로 모두 교체한다. 이후 트랜잭션 commit 시점에 변경 감지 기능이 동작해서 데이터베이스에 UPDATE 쿼리를 날려준다. 변경 감지 기능과의 차이점으로 인한 단점 → 부분수정이..
사용 라이브러리 Spring Web Lombok Thymeleaf Spring Data JPA H2 도메인 모델과 테이블 설계 회원 기능 등록 조회 상품 기능 등록 수정 조회 주문 기능 주문 내역 조회 취소 controller, web: 웹 계층 service: 비즈니스 로직, 트랙잭션 처리 repository: JPA를 직접 사용하는 계층, 엔티티 매니저 사용 domain: 엔티티가 모여 있는 계층, 모든 계층에서 사용
스프링 빈의 이벤트 라이프 사이클(Singleton Scope) 스프링 컨테이너 생성 ▶ 스프링 빈 생성 ▶ 의존관계 주입 ▶ 초기화 콜백 ▶ 사용 ▶ 소멸전 콜백 ▶ 스프링 종료 초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출 소멸전 콜백: 빈이 소멸되기 직전에 호출 스프링의 콜백 지원 방법 3가지 인터페이스(InitializingBean, DisposableBean) 인터페이스를 상속 받아서 생성과 소멸의 시기에 호출을 하는 방법. 이 인터페이스는 스프링 전용 인터페이스이기 때문에 스프링 전용 인터페이스에 의존한다. 초기화, 소멸 메서드의 이름을 변경할 수 없고 내가 코드를 고칠 수 없는 외부 라이브러리에 적용을 할 수 없다. → 예전에 사용하던 방식으로 거의 사용하지 않는다. 빈..
결론부터 말하면 편리한 자동 기능을 기본으로 사용하자. 스프링이 나오고 나서 점점 자동화 되는 기능을 선호하는 추세이고 설정 정보를 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 번거로움을 줄일 수 있는 이런 과정을 선호하는 이유는 편리함도 있지만 관리할 빈이 많아서 설정 정보가 커지면 설정 정보를 관리하는 것 자체가 부담이 될 수 있기 때문이다. 그렇다면 수동 빈 등록은 언제 사용하면 좋을까? 업무 로직과 기술 지원 로직으로 나누어서 생각을 해보자. 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비지니스 요구사항을 개발할 때 추가되거나 변경된다. → 숫자들이 엄청 중..
int number = 50; //2진수로 변환 String nBi = Integer.toBinaryString(number); //변환된 2진수에서 1이 몇개 있는지 확인 int count_1 = Integer.bitCount(number);
