DevBoi

사용을 위한 기본구성 1. JpaFactory package com.practice.demo.config; import com.querydsl.jpa.impl.JPAQueryFactory; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import javax.persistence.EntityManager; @Configuration public class JpaFactory { @Autowired EntityManager em; @Bean ..

상태 필드 : 단순히 값을 저장하기 위한 필드 연관 필드 : 연관관계를 나타내기 위한 필드 -단일값 연관 필드 : many to One이나 one to one 처럼 연관 관계가 엔티티 하나일때 -컬렉션 값 연관 필드 : 엔티티 하위에 컬렉션 으로 가지고있는 데이터 상태 필드 -> 경로 탐색의 끝 , 더이상 탐색하지 않는다 연관 필드 -> member 하위에 team이 있는 경우, team을 select하면, 묵시적인 inner join이 발생한다.  team 하위의 값을 탐색하고 싶으면 m.team.teamName 이런식으로 작성하면되고, 이런식으로 select하면 join이 발생하는 것을 묵시적 내부 조인이라고 표현한다 컬렉션 연관관계 경로도, 묵시적 내부조인이 발생하지만, 하위 내용을 조회할수는없다..

SQL은 데이터 베이스 테이블을 대상으로 쿼리를 하지만 JPQL은 엔티티 객체를 대상으로 쿼리를 한다,. 또한 SQL을 추상화해서, 특정 데이터베이스 SQL에 의존적이지 않다. 간단한 예다. 동적 쿼리를 생성하기에는 ibatis와 mybatis가,편하긴 하지만 jpa에서도 장점은 있다. Criteria를 쓰면, 동적 쿼리에 대한 생성이되지만, 실무에서 쓰기에는 유지보수가 말이안된다. 그래서 동적 쿼리는 Criteria보다, QueryDSL로 많이 사용한다고 한다. QueryDsl 은 오픈소스이다. 이 기술은, 자바 처럼 실수로 오타가 나면 디버깅이 바로 표기되기 떄문에 빠르고 동적 쿼리로 생성되기에 겉 형태가 sql과 비슷하여, 눈에 잘들어온다는 장점이 있다. 또한 자바 쿼리라서 재사용 또한 가능하다. ..

영속성 관련되서, Parent와 child를 persist할때 1:N 관계여도, parent와 child를 다 persist해줘야 한다. 예를 들어, 해당 과 같은 소스에서 차일드가 2개이고, 부모가 한개인 경우에는 총 3번의 persist를 해줘야 쿼리가 3개 다 나간다. 한번 persist를 빼보자 add를 해도, parent만 저장이된다. 이런 케이스때는 일일히 결국 persist를 해줘야 할까? 아니다. 영속성 전이를 이용하면 편하다 동일 소스 여도, 영속성 전이가 되어서 insert가 3개 다 나가는 것을 볼수있다. -라이프사이클이 유사할때,(등록,삭제) -소유자가 하나일때, child를 가지는게 parent하나일때, 위 두가지일때 쓰는것이 좋다. 고아 객체 부모엔티티와 연관관계가 끊어진 자식 ..

두 객체에 대한 로딩을 할때, 해당 처럼 Lazy 조인으로 하게되면, 해당 컬럼을 지연 로딩을 할수 있다. 그렇게 되면, 해당 find할때 팀을 가져오는 것이아니라, 실제로 팀을 사용할때 가져오는 쿼리를 발송한다. 이는 프록시를 활용한 것이다. 처음에 멤버를 가져올때 팀은 프록시 객체만 가져오고, 실제로 팀을 사용할때, 해당 팀에 대해서 영속성 컨텍스트에게 프록시 객체가 초기화 요청을 하여 쿼리가 나가는 것이다. 지연 로딩의 반대는 FetchType.eager이면서 즉시로딩이라고한다. 해당 방법으로 엔티티를 가져오면, 프록시 객체가 아닌, 관련된 엔티티들을 조인으로 전부를 진짜 객체로 가져온다. 가급적 실무에서는 지연 로딩을 사용해야한다 왜냐면 즉시로딩은 한번의 엔티티에 다른 엔티티들에 대한 조회를 같이..

만약에 공통된 컬럼을 공통된 테이블에 다 쓴다? 예를 들어 수정,생성 시간에 대한 모든 값을 테이블 마다 필요하다라는 조건이 생겼다고 가정하자 요런 BaseEntity를 공통으로 가진다고 한다면, 요로케 category나, 슈퍼클래스에 대한 상속을 받으면 된다. 그렇게 되면 category에 대한 테이블은 아래와 같이 설계가 된다. 이렇게 슈퍼클래스에 대한 값도 테이블에 가지고 있게 된다. 참고로 Entity 클래스는 같은 Entity 나, mappedbySuperClass에 대한 것만 상속이 가능하니 참고해야한다.

자바나 객체는 상속관계가 존재하지만, 관계형 디비에는 해당 상속관계가 존재하지 않는다. 쉽게 말하면 상속관계 매핑은, 객체의 상속관계를 디비의 슈퍼타입 서브타입으로 매핑하는 것을 의미한다. 참고로 슈퍼타입 서브타입에 대해서는 별도 포스팅으로 진행하겠다. 무튼 이렇게 상속 관계 에 있을때 jpa 엔티티 설게를 다음 과 같이 했다고 가정한다. 뭐 굳이 코멘트가 필요 없을 정도이지만, 무튼 Movie라는 엔티티가 있고 뮤직과 북이 이 무비를 상속 받아서, 엔티티를 한다고 가정하자, 이대로 구동하면 디비 테이블 설계 쿼리는 아래와 같이 나간다. Hibernate: create table movie (dtype varchar(31) not null, id bigint not null, name varchar(25..

1. JoinTable 생성 JoinTable은, 특정 두가지의 엔티티의 매핑관계를 가지는 매핑테이블이라고 이해하면 쉽다. A,B라는 객체가 서로 매핑이 되어있는 경우, 이를 관리하기 위해 매핑테이블을 가지고, 이 매핑 테이블을 보고 두 객체의 매핑관계를 파악한다. 예 ) 카테고리, 아이템 카테고리 객체에서 해당 itemList를 볼수있는, manyto many를 사용해서 이렇게 조인 테이블을 만든다. 그러면 해당 엔티티 객체에서 해당 테이블이 생성이 된다.

연관관계에 대한 매핑 시 주의사항에 대한 공부를 했었고, 해당 공부를 진행하면서 많은 고민을 했었다. 실제로 구현 및 설게를 해보자 Member, Team, order, orderItem에 대한 설게를 해보자. 우선 사전 제약 사항에 대한 설정을 해보자 Member들은 각각의 정보를 가지고있고, 이 Member들에게는 Team의 정보가 포함이 된다. 어떤 Member는 team에 한군데 소속이 될수 있다. 또한 Member가 order들을 가질수있고, 이 order들에게는 orderItem들이 존재할수있다. 마지막으로 orderItem이 order와 item을 이어주는 것이라고생각을 하면 되고, Item은 이 Item에 대한 세부항목 정보이다. 1)Member 해당, memberId는 자동 id 값을 발..

일단 jpa 관련 예시 소스를 한번 보자 Team과 member에 대한 연관관계를 잘 생각해보자 이런 경우에, Team이 연관관계에 주인이라고 할수있다. 이렇게 member에서 가져다가, team에 대한 정보를 update 및 저장 등을 한다고 가정해보자 즉 모든 멤버는 각자 소속된 팀이 있거나, 없다. 이제 Member를 만들고, 이 멤버에 Team을 set해보자 db에는 어떻게 담기게될까?? Member의 Team을 set하였고, 해당 Member를 set, persist를 하게되면, 저렇게 db에 담기게된다. 그런데, 만약에 한 로직에서, flush가 되지않고, 1차 캐시에 값이 남아있는 상태로 find하게되면? add되지않은 상태에서, 값이 find 될 경우가 있다. (트랜잭션 관리) 따라서, 해..