Goyummy

JPQL은 엔티티 객체를 대상으로 쿼리. SQL은 데이터베이스 테이블을 대상으로 쿼리.JPQL을 한마디로 정의하면 객체 지향 SQL 하지만, JPQL로 동적 쿼리를 작성하기 불편하다.. Criteria //Criteria CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder(); CriteriaQuery query = criteriaBuilder.createQuery(Member.class); Root m = query.from(Member.class); String username = "aaaa"; CriteriaQuery cq = quer..

JPA는 데이터 타입을 두가지로 분류엔티티 타입@Entity로 정의하는 객체데이터가 변해도 식별자로 지속해서 추적 가능예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능.값 타입int, integer, string처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체식별자가 없고 값만 있으므로 변경시 추적 불가예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체값 타입은 기본값 타입, 임베디드 타입, 컬렉셔 값 타입이 있다.기본 값 타입자바 기본 타입(int, double)래퍼 클래스(Integer, Long)String임베디드 타입(복합 값 타입)컬렉션 값 타입기본 값 타입생명 주기를 엔티티에 의존회원을 삭제하면 이름, 나이 필드도 함께 삭제값 타입은 공유하면 안됨회원 이름 변경 ..

프록시멤버와 팀이 연관된 정보라고 했을 때, 어떤 경우에는 멤버만 가져오고 싶고, 어떤 경우에는 멤버와 팀을 다 가져오고 싶을 수 있다.  프록시 기초em.find() vs em.getReference()em.find(): 데이터베이스를 통해서 실제 엔티티 객체 조회em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 getReference()를 호출하는 시점에는 데이터베이스의 쿼리를 안하고, 실제 사용되는 시점에 쿼리를 날린다. getId로 사용할 때는 데이터베이스에서 가져오는 것이 아니라서 쿼리를 날리지 않는다. 프록시는 실제 클래스를 상속받아서 만들어지고, 실제 클래스와 겉 모양이 같다. 프록시 객체는 실제 객체의 참조(target)을 보관하고, 프록시 객체를..

상속 관계 매핑관계형 데이터베이스는 상속 관계가 없음슈퍼 타입 서브 타입 관계라는 모델링 기법이 객체 상속과 유사함상속 관계 매핑: 객체의 상속 구조와 DB의 슈퍼 타입 서브 타입 관계를 매핑슈퍼 타입 서브 타입 논리 모델을 실제 물리 모델로 구현하는 방법각각 테이블로 변환 -> 조인 전략장점테이블 정규화외래키 참조 무결성 제약조건 활용 가능저장공간 효율적 단점조회 쿼리가 복잡함조회시 조인을 많이 사용데이터 저장시 Insert sql 2번 호출@Inheritance(strategy = InheritanceType.JOINED)통합 테이블로 변환 -> 단일 테이블 전략@DiscriminatorColumn이 없어도 DTYPE이 생김.장점조인이 필요 없어서 일반적으로 조회 성능이 빠름조회 쿼리가 단순함단점자식..

연관 관계 매핑시 고려사항 3가지다중성다대일일대다일대일다대다: 실무에서 쓰면 안됨. 단방향, 양방향테이블은 외래 키하나로 양쪽 조인 가능해서 방향이라는 개념이 없음객체는 참조용 필드가 있는 쪽으로만 참조 가능. 한쪽만 하면 단방향, 양쪽이 서로 참조하면 양방향(단방향 두개) 연관 관계의 주인: 외래 키를 관리하는 참조다대일관계형 데이터베이스에서는 다(N)쪽에 항상 외래키가 들어가줘야 한다.1쪽에 외래키를 두면 여러개를 설정해야 하니까가장 많이 사용하는 연관 관계반대는 일대다다대일 단방향//멤버 -> 팀 @ManyToOne //멤버 입장에서는 멤버가 N @JoinColumn(name = "TEAM_ID") //조인할 컬럼 private Team team; 아래 코드처럼 다대일 양방향은 반대..

객체의 참조와 테이블의 외래 키를 매핑객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.테이블은 외래 키로 조인해서 연관된 테이블을 찾고, 객체는 참조를 사용해서 연관된 객체를 찾는다.  단방향 연관 관계@Entity//@Table(name = "USER") 객체와 데이터베이스 테이블의 이름이 다를 때public class Member { @Id @GeneratedValue @Column(name = "MEMBER_ID") private Long id; @Column(name = "USERNAME") private String username;// @Column(name = "TEAM_ID")// private Long teamId; ..

객체와 테이블 매핑: @Entity, @Table필드와 컬럼 매핑: @Column기본 키 매핑: @Id연관 관계 매핑: @ManyToOne, @JoinColumn객체와 테이블 매핑@Entity@Entity가 붙은 클래스는 JPA가 관리하고, 엔티티라 한다.기본 생성자가 필수다.(public이나 protected)JPA를 사용해서 테이블과 매핑할 클래스는 @Entity가 필수다.속성: nameJPA에서 사용할 엔티티의 이름을 지정기본 값은 클래스 이름을 그대로 사용같은 클래스 이름이 없으면 가급적 기본값을 사용한다. @Table엔티티와 매핑할 테이블 지정속성name: 매핑할 테이블 이름. 기본값은 엔티티 이름을 사용catalog: 데이터베이스 catalog 매핑schema: 데이터 베이스 schema 매핑..

웹 어플리케이션 개발을 한다고 하면 엔티티 매니저 팩토리가 고객의 요청이 올때마다 엔티티 매니저를 생성해서 내부적으로 DB와 커넥션을 생성하여 요청을 처리한다.  영속성 컨텍스트엔티티를 영구 저장하는 환경EntityManager.persist(entity);사실 DB에 저장한다는게 아니라 영속성 컨텍스트에 저장한다.EntityManager 안에 영속성 컨텍스트라는 보이지 않는 공간이 생긴다.영속성 컨텍스트 내에 1차 캐시가 있어서 em.find()로 조회할 때, 1차 캐시에 있을 경우에는 select문이 안나간다. 하지만 1차 캐시는 하나의 트랜잭션 안에서만 효과가 있어서 성능적인 이점은 크게 있지는 않다.영속 엔티티의 동일성 보장같은 primaryKey를 여러번 조회했을 때, ==으로 동일성을 비교하면..

JPA 구동 방식JPA는 Persistence라는 클래스가 있다.Persistence에서 시작해서 설정 정보를 조회하여 EntityManagerFactory라는 클래스를 만든다.EntityManagerFactory는 애플리케이션 전체에서 공유필요할 때마다 EntityManager를 찍어내서 사용한다. EntityManager는 쓰레드 간에 공유를 하지 않음. (사용하고 버려야 함)EntityManagerFactory는 애플리케이션 로딩 시점에 딱 하나만 만들어야 한다.실제 DB에 저장하는 트랜잭션 단위(DB커넥션을 얻어서 쿼리를 날리고 종료)는 EntityManager를 만들어줘야 한다.JPA에서는 트랜잭션 단위가 매우 중요하다. 모든 작업은 트랜잭션 안에서 작업을 해야 한다.  코드 예제Member 객..

SQL 중심적인 개발의 문제지금 시대는 객체를 관계형 DB에 관리CRUD, ... 무한 반복, 지루한 코드. 계속 쿼리를 작성해야객체에는 상속 관계가 있지만, 데이터베이스에는 상속 관계가 없음.슈퍼 타입, 서브 타입으로 설계해야함.조회 시에도 조인해서 해야함. => 객체를 테이블에 맞춰서 설계해야함. ORM (Object - relational mapping, 객체 관계 매핑)객체는 객체대로 설계관계형 데이터 베이스는 관계형 데이터베이스 대로 설계ORM 프레임워크가 중간에서 매핑JPA를 왜 사용해야 하는가SQL 중심적인 개발에서 객체 중심으로 개발생산성유지보수패러다임의 불일치 해결성능데이터 접근 추상화와 벤더 독립성표준 저장: jpa.persist(member)조회: Member member = jpa...