DevBoi

JPA 동작 과정 -저장 과정 JPA 의 경우 트랜잭션 실행 단위 안에서 동작한다. 엔티티를 조회,저장,수정등 작업이 일어나면 SQL문이 DB에 적용되는 것이 아니라 쓰기지연 SQL저장소라는 곳에 SQL이 쌓이게 된다. 이렇게 생성된 SQL문들은 트랜잭션 플러시가 일어나는 경우 DB에 쿼리를 보내게 된다. -수정 과정 수정할 엔티티를 찾는다. 1차 캐시에 올라가고 영속상태가 된다. 영속성 컨텍스트가 관리하는 상태가 된다. JPA는 데이터 베이스 트랜잭션 커밋 시점에 변경감지 기능을 사용하게 된다. 1차 캐시에 등록된 상태의 스냅샷과 해당 엔티티를 비교해서 변경내역을 확인하고 (변경감지, dirty checking) update 쿼리를 쓰기지연 저장소에 저장하고 트랜잭션이 끝나기 전에 해당 쿼리를 날리고 ..

영속성 컨텍스트란 엔티티를 영구 저장하는 환경이라는 뜻이다. 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. 엔티티 매니저를 통해 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다. -특징 엔티티 매니저를 생성할때 하나 만들어진다. 엔티티 매니저를 통해서 영속성 컨텍스트에 접근하고 관리할 수 있다. -이점 1차 캐시 영속성 컨텍스트에는 1차 캐시가 존재한다. 엔티티를 영속성 컨택스트에 저장하는 순간 1차캐시에 객체가 key,value값으로 저장된다. 엔티티 매니저가 값 을 조회할때 엔티티가 존재하는 경우 DB조회를 하지 않고, 바로 리턴해준다. 동일성 보장 영속성 컨택스트에서 꺼내온 객체는 동일성이 보장된다. 같은 엔티티를..

엔티티의 생명주기는 4가지가 있다. 1. 비영속 - 영속성 컨텍스트와 전혀관계가 없는 상태 - 객체를 생성만 한 상태 2. 영속상태 - 영속성 컨텍스트에 저장된 상태 - 엔티티가 영속성 컨텍스트에 의해 관리되는 상태 3. 준영속 상태 - 영속성 컨텍스트에 저장되었다가 분리된 상태 - 영속성 컨텍스트에서 지운 상태 - 준영속 상태에서는 영속성 컨텍스트가 제공하는 기능을 사용하지 못한다.(Dirty Checking, Update Query) (이름 변경에 대한 Entity 데이터 변화를 감지한다. 1차 캐시의 snapshot이 다른것을 감지하면, update query 를 날린다.) 4. 삭제 상태 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제한 상태이다.

1. ORM이란? Object Relational Mapping 의 약자로, 이름 그대로 객체와 관계형 데이터를 매핑하기 위한 기술이다. 객체와 관계형 데이터 베이스는 패러다임의 불일치가 존재할수 밖에없고, 해당 패러다임을 맞추려, 객체지향적 설계를 할수 없다. ORM은 이러한 문제를 해결한다. 2. JPA java persistence APi의 약자로, 자바 ORM 기술에 대한 API 표준 명세이다. 즉, 인터페이스 모음이다 이 인터페이스를 구현한 프레임워크가 하이버네이트이다. JPA는, 애플리케이션과 JDBC 사이에서 동작하며, JPA를 개발자가 사용하면, JPA 내부에서 JDBC API를 사용하여, SQL을 호출하여 DB와 통신한다. 3. 하이버네이트 JPA를 구현한 프레임워크 중 사실상 표준에 가..

더티 체킹때문에, 실시간 성은 굉장히 좋은 효과를 가지지만 bulk 성 연산에는 약한것같다. 그래서 기능은 있다고 한다. 쿼리 한번으로 여러 테이블 로우를 변경한다. 벌크 연산 주의 벌크 연산은 영속성 컨텍스트를 무시하고 디비에 직접 쿼리한다. - 벌크 연산을 먼저 실행한다. - 벌크 연산 수행 후 연속성 컨텍스트 초기화 한다. 해당 주의사항을 했던 이유는 많은 량의 데이터가 변경되기 때문에, 영속성 컨턱스트를 통해 값을 받게 되면 해당 애플리케이션과 실제 디비의 갑이 다르게 될수 있기 때문이다. Spring data jpa 에서는 Modifying하는 어노테이션이 있는데, 이건 영속성 컨텍스트를 한번 clear 시켜주는 것이다.

Named 쿼리는 쿼리에 대한 실제 이름을 붙일수있다. 즉 query id 를 부여할수있다. - 정적 쿼리만 가능 - 어노테이션, XML 에 정의 - 애플리케이션 로딩 시점에 초기화 후 재사용 - 애플리케이션 로딩 시점에 쿼리를 검증 sql로 파싱해서, 캐싱하고있다.

SQL 조인 기능이 아니다. JPQL에서 성능 최적화를 위해서 사용된다. 연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회하는 기능이다. join fetch 명령어를 사용한다. 이런식으로 join fetch를 하게 되면 내부적으로 inner join이 발생되어서, 해당 쿼리는 한번만으로 조회를 전부 해온다. Lazy fetch type이여도, 프록시 엔티티가아닌, 실제 엔티티 값으로 가져온다. (Team도) 컬렉션 타입을 공부해보자 이런식으로 팀의 member들에 대한 리스트를 가지고있다고 가정해보자 팀은 총 2개인데, 팀을 가진 member가 3인 경우? 총 3개가 노출이된다. 응? 팀을 select 했는데, 왜 3개가 되지 이런경우 사용되는게 바로, distinct이다. Team 하위 멤버가 2개이면..

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

jpa는 해당 두개로 페이징을 추상화 했다. 이렇게 하면, 1번째 부터 3개까지, 총 3개를 반환한다. 정말 쉽게 페이징 기능이 구현된다. 개꾸르 추가로 inner join 이나 조인등은 이렇게 사용한다. 자동으로 pk에 대한 ==이 적용된다고 생각하면 된다. 외부 조인도 가능하고, 연관관계가 없는 엔티티 끼리도 외부조인까지 가능하다 하이버네이트 5.1부터는 연관관계가 없는 엔티티끼리도 외부조인이 가능하다 내부조인만 원래는 가능했다고 한다 from 절의 서브쿼리는 JPQL에서 불가능하다고 한다. -> join으로 앵간하면 풀어서 해결한다. 아니면 native SQL로 해결한다. case 문이나, 기타 쿼리도 동일하다. 오라클의 nvl 과 값이 같으면 Null을 반환해주는 펑션들도있으니 유용하게 사용하면 ..

JPQL : java persistance query language JPQL은 엔티티 객체를 대상으로 쿼리한다. JPQL은 SQL을 추상화해서 특정 데이터베이스 SQL에 의존하지 않는다. JPQL의 특징 -엔티티와 속성은 대소문자를 구분한다. -JPQL 키워드는 대소문자를 구분하지 않는다. -엔티티 이름을 사용하고, 테이블 이름을 사용하지 않는다. -별칭을 필수이다. TypeQuery, Query TypeQuery -> 반환타입이 정확할때 Query -> 반환타입이 부정확할때 query.getResultList() -> 결과가 하나이상일때, 리스트 반환 -> 결과가 없으면 빈 리스트 반환 query.getSingleResult() -> 결과가 정확하게 하나 여야한다. 둘이상이거나, 0이면, Except..