URI URI는 로케이터(locator), 이름(name)을 포함한 개념이다. URI는 다음과 같이 풀이할 수 있다. Uniform: 리소스 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL, URN URL, URN은 다음과 같이 풀이할 수 있다. URL: Uniform Resource Locator : 리소스가 있는 위치를 지정 URN: Uniform Resource Name : 리소스에 이름을 부여 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않아, 잘 사용하지 않는다.

페치 조인 (Fetch Join) 페치 조인은 JPQL에서 연관된 엔티티나 컬렉션을 SQL 한 번에 함께 조회하는 기능을 한다. 사용 문법은 다음과 같다. 1 페치 조인 ::= [ LEFT [OUTER] | INNER ] JOIN FETCH 조인경로 페치 조인은 SQL 한 번으로 연관된 엔티티들을 함께 조회할 수 있어서 SQL 호출 횟수를 줄여 성능을 최적화할 수 있다. 페치 조인은 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선한다. 실무에서는 글로벌 로딩 전략은 모두 지연 로딩이므로, 최적화가 필요한 곳은 페치 조인을 적용하면 효과적이다.

상속관계 매핑 객체는 상속관계가 존재하지만, 관계형 데이터베이스는 상속 관계가 없다. 그나마 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사하다. 상속관계 매핑이라는 것은 객체의 상속 구조와 DB의 슈퍼타입 서브타입 관계를 매핑하는 것이다. DB의 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법은 세가지 있다. DB입장에서 세가지로 구현하지만 JPA에서는 어떤 방식을 선택하던 매핑이 가능하다. 주요 어노테이션 @Inheritance(strategy=InheritanceType.XXX) JPA가 DB의 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 세가지 방식과 매핑하려면 @Inheritance(strategy=InheritanceType.XXX)의 stategy를 설정해주면 된다.

양방향 매핑은 단방향 매핑에서 반대 방향으로 객체 조회(객체 그래프 탐색) 기능이 추가된 매핑 방법이다. 아래와 같은 연관 관계가 있다고 가정하자. 예제 시나리오 회원과 팀이 있다 회원은 하나의 팀에만 소속될 수 있다. 회원과 팀은 다대일 관계다. 위의 시나리오를 구현하기 위해서 Member(=회원), Team Entity를 작성해보자. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 package hello.

영속성 컨텍스트 처음 생성된 엔티티 매니저 팩토리는 클라이언트의 요청에 따라 엔티티 매니저를 생성한다. 그리고 엔티티 매니저는 DB Connection Pool에 있는 Connection을 이용해서 DB에 접근한다. 영속성 컨텍스트란 엔티티를 영구 저장하는 환경이다. 영속성 컨텍스트는 논리적인 개념이며, 눈에 보이지 않는다. 엔티티 매니저를 통해서 영속성 컨텍스트에 접근한다. 엔티티의 생명주기 비영속(new/transient) 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태. 객체를 단순히 생성한 상태 영속(managed) 영속성 컨텍스트에 의해 관리되는 상태 객체를 생성한 뒤 엔티티 매니저를 통해 persist 해주면 영속 상태가 된다.

SQL 중심적인 개발의 문제점 SQL에 의존적인 개발을 피하기 어렵다. 패러다임의 불일치 (객체 vs 관계형 데이터베이스) 객체와 관계형 데이터베이스의 차이 상속 객체는 상속과 다형성을 사용 테이블은 상속 관계 안쓴다. 연관관계 객체는 참조를 사용 관계형 데이터베이스는 외래 키를 사용 연관관계 탐색 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다. 관계형 데이터베이스는 처음 실행하는 SQL에 따라 탐색 범위 결정 데이터 식별 방법 관계형 데이터베이스는 처음 실행하는 SQL에 따라 탐색 범위 결정되기 때문에, 이는 엔티티 신뢰 문제를 발생시킨다.