Just Do (82) 썸네일형 리스트형 RS) 연관관계 매핑 기초 객체와 테이블 연관관계의 차이를 이해 객체의 참조와 테이블의 외래 키를 매핑 용어 이해 방향 : 단방향, 양방향 다중성 : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M) 이해 연관관계의 주인(Owner) : 객체 양방향 연관관계는 관리 주인이 필요 문제가 되는 코드를 살펴보자 Member 엔티티 안에 teamId를 들고있으면, 연관관계가 없을 경우에 아래와 같이 문제가 있다. 객체지향 스럽지 않다는 뜻이다. @Entity public class Member { @Id @GeneratedValue @Column(name = "MEBMER_ID") private Long id; @Column(name = "USERNAME") private String username; // teamI.. RS) 실전예제를 통한 문제점 분석 ORDER 엔티티 작성시에 문제가 되는 코드 @Entity @Table(name = "ORDERS") public class Order { @Id @GeneratedValue @Column(name = "ORDER_ID") private Long id; @Column(name = "MEMBER_ID") private Long memberId; 위와같이 ORDER 엔티티에 멤버 ID가 포함되어 있는데 이렇게 될 경우.. 메인함수를 불러주는 부분에서.. public class JpaMain { public static void main(String[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello"); Enti.. RS) 기본키 매핑 기본 키 매핑 어노테이션 @Id (직접 할당) 직접 할당하는 경우 @Id만 사용 @GeneratedValue (자동 생성) GeneratedValue 전략 IDENTITY : 데이터베이스에 위임, MYSQL "나는 모르겠고, DB야 니가 알아서 해줘" 라는 의미의 전략 ID 값을 알 수 있는 시점이 DB에 값이 들어가야만 알 수 있다. 영속성 컨텍스트에서 관리하려면(PK = ID)값이 있어야하는데, 이점이 문제가 된다. 그래서 원래는 트랜잭션이 커밋되었을 때 INSERT 쿼리가 디비로 날라가야하는데 IDENTITY 타입의 전략에서만 예외적으로 em.persist 하는 순간 INSERT 쿼리가 날라가게 된다. public class Member { @Id // GeneratedValue 전략이 IDENTI.. RS) 필드와 컬럼 매핑 매핑 어노테이션 정리 @Column - 컬럼 매핑 (엔티티와 디비에서의 컬럼이 다를 경우) 세부 속성 정리 name : 필드와 매핑할 테이블의 컬럼 이름 insertable, updatable : 등록, 변경 가능 여부 / 기본 값 : True nullable(DDL) : null 값의 허용 여부를 설정한다. false로 설정하면 DDL 생성시에 not null 제약조건이 붙는다. unique(DDL) : @Table의 uniqueConstraints와 같지만 컬럼에 간단히 유니크 제약조건을 걸 때 사용 복합으로는 사용할 수 없다 컬럼 명 자체에 거는 것은 사용하지 않는다. // 잘못된 예시 @Entity public class Member { @Id private Long id; // username .. RS) 객체 테이블 매핑 @Entity 어노테이션 @Entity가 붙은 클래스는 JPA가 관리를 하겠다라는 엔티티를 나타낸다. JPA를 사용하여 테이블을 매핑하기 위해서는 @Entity를 필수로 가져야한다. 주의 점 기본 생성자를 필수로 가져야한다 (파라미터가 없는 public 또는 protected 생성자) final 클래스, enum, interface, inner클래스 사용 X 저장할 필드에 final 사용 X @Table 어노테이션 @Table은 엔티티와 매핑할 테이블 지정 name : 매핑할 테이블 이름 → 기본 값 : 엔티티 이름을 사용 catalog : 데이터베이스 catalog 매핑 schema : 데이터베이스 schema 매핑 uniqueConstraints : DDL 생성 시에 유니크 제약 조건 생성 데이터베이.. RS) 준영속 상태 영속 상태 : JPA 관리하에 들어가는 상태 크게 두가지 경우의 상태가 있는데 em.persist() 하여 영속성 컨텍스트에 1차 캐시에 올라가는 경우 em.find() 를 했는데 1차 캐시에 없는 경우 데이터베이스에 들리고 가져올 때 1차캐시에 넣어주면서 영속상태가 되는 경우 준영속 상태 영속 상태의 엔티티가 영속성 컨텍스트에서 분리되는 상태(detached) 영속성 컨텍스트가 제공하는 기능을 사용 못함 준영속 상태로 만드는 방법 em.detach(entity) - 특정 엔티티만 준영속 상태로 전환 try{ // 영속 Member member = em.find(Member.class, 150L); member.setName("AAAAA"); // 영속 -> 준영속 상태 em.detach(member);.. RS) 플러시(flush) 플러시(flush)란? 영속성 컨텍스트의 변경내용을 데이터베이스에 반영하는 것 플러시가 발생되면? 변경 감지 수정된 엔티티 쓰기 지연 SQL 저장소에 등록 쓰기 지연 SQl저장소의 쿼리를 데이터베이스에 전송(등록, 수정, 삭제 쿼리) 영속성 컨텍스트를 비우는 것이 아니다. 플러시하는 방법 em.flush() : 직접 호출방법 트랜잭션 커밋 : 플러시 자동호출 JPQL 쿼리 실행 : 플러시 자동호출 try{ Member member = new Member(200L, "member200"); em.persist(member); // 플러시 했기때문에 하단에 ===== 하기전에 쿼리가 날라간다. // 직접 여기서 플러시 하지 않아도 하단에 트랜잭션을 커밋하게 되면 자동으로 플러시된다. em.flush(); S.. RS) 영속성 컨텍스트 영속성 컨텍스트란? JPA를 이해하기 위한 가장 중요한 용어 EntityManager.persist(entity); persist 하는 순간 엔티티를 영속성 컨텍스트에 만든다. (영속화 한다) 엔티티 매니저를 통해서 접근한다. 눈에 보이지 않는 공간이 생긴다. 엔티티의 생명주기 비영속 - 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 // 객체를 생성한 상태로 (비영속 상태) Member member = new Member(); member.setId("member1"); member.setUsername("회원1"); 영속 - 영속성 컨텍스트에 관리되는 상태 - 영속상태가 됬다고 바로 DB에 쿼리가 날라가는 것은 아니다. - 트랜잭션 커밋하는 순간 DB에 쿼리가 날라간다. // 객체를 생성한 상태로 .. 이전 1 2 3 4 5 ··· 11 다음
