DevBoi

플러시 (Flush) -영속성 컨텍스트의 변경 내용을 DB에 반영하는 것을 말한다. -Transaction commit 이 일어날때 flush가 동작하는데, 이때 쓰기 지연 저장소에 쌓아놨던 insert, update,delete sql들이 DB에 날아간다. (영속성 컨텍스트를 비우는 건아니다) -영속성 컨텍스트의 변경사항들과 DB의 상태를 맞추는 작업이다. (영속성 컨텍스트의 변경 내용을 DB에 동기화한다.) 플러시 동작 과정 1. 변경을 감지한다 (Dirty checking ) 2. 수정된 Entity를 쓰기 지연 SQL 저장소에 등록한다. 3. 쓰기 지연 SQL 저장소의 Query를 DB에 전송한다. Flush 발생한다고 해서, commit 이 이루어지는 것은 아니고, Flush 이후에 commit..

격리성은 동시에 실행되는 트랜잭션이 서로에게 영향을 미치지 않도록 격리한다. 격리 수준에는 다음과 같다 * READ UNCOMMITED(커밋되지 않는 읽기) 트랜잭션 A가 특정 컬럼 데이터를 변경하고 있는 중에, 트랜잭션 B가 read하면, A가 변경한 데이터를 읽어온다. -문제 : dirty read, 트랜잭션 A가 특정 컬럼 데이터를 변경하고 rollback했을때 발생한다. * READ COMMITED(커밋된 읽기) 트랜잭션 A가 특정 컬럼 데이터를 변경하고 있는 중에, 트랜잭션 B가 read하면 트랜잭션 A가 변경하기 전 데이터를 읽어온다. 만약 트랜잭션 A가 데이터 변경후, 커밋하게되면 트랜잭션 B는 변경된 데이터를 읽어온다. -> 즉, 한트랜잭션 내에서 외부 요인의 데이터 변경 커밋이 반영되어 ..

JPA : java persistence api 약자, 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다. Hibernate : jpa의 구현체이다.

엔티티가 getter 와 setter를 가지고 있으면, Controller단이 아니라 어디서든 실수로 쉽게 속성이 변경될 수 있다. 또한 DB의 테이블 스키마와 같은 구조이기 때문에 테이블 설계가 노출된다. DTO를 이용하면 필요한 모든 값들을 하나의 DTO에 담아서 보내줄수 있으므로, 개인적으로 Front단에서 편하게 작업 가능 필요없는 속성은 굳이 보내지 않아도된다. 가장 중요한 부분 순환참조를 예방할 수 있다. JPA로 개발할때, 양방향 참조된 엔티티를 컨트롤러에서 응답으로 return하게 되면, 엔티티가 참조하고 있는 객체는 지연로딩되고, 로딩된 객체는 또 다시 본인이 참조하고있는 객체를 호출하면서 무할 루프에 빠질 수 있다. 정리 )DTO를 사용하면 아래와 같은 상황에서 유리하다 1. 실수로 속..

1. Entity에는 가급적 Setter 사용을 하지 않는 것이 좋다. - 변경 포인트가 너무 많으면 유지보수가 어렵다. 2. 모든 연관관게는 지연로딩으로 설계하자 - 즉시로딩은 예측이 어렵고, 어떤 SQL이 실행될지 추적이 어렵다. 그리고 JPQL을 실행할때 N+1 문제가 자주 발생한다. 만약 즉시로딩이 필요하면, Fetch join이나 엔티티 그래프 기능을 사용한다. 3. 컬렉션을 필드에서 초기화 하자 -컬렉션은 필드에서 바로 초기화 하는 것이 null 문제에서 안전하다. -하이버네이트는 Entity를 영속화할때 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 4.테이블, 컬럼명 생성 전략 - 스프링 부트에서 하이버네이트 기본 매핑 전략을 변경해서 실제 테이블 필드명이 다르다. ( ..

엔티티 그래프 : 엔티티 조회시점에 연관된 엔티티들을 함께 조회하는 기능 -정적으로 정의하는 Named 엔티티 그래프 -동적으로 정의하는 엔티티 그래프 정적 엔티티 그래프 해당 같은 케이스 때, Order을 조회하면, member를 엔티티 그래프에 정의하였기 때문에 Member도 같이조회를 한다.(패치 전략이 지연로딩이여도 적용된다.) 실제로 repository에서 사용을 한다고하면, 아래와 같다. Named 엔티티 그래프는 정적으로 정의한다. 추가로, 기존 전략이 정적으로 선언이 되어있다고 해도 코드를 활용하여, 값을 가져올때, Map 형태로 엔티티 그래프를 가져와서, 서브 그래프를 추가하고, 노드 속성을 추가하여, 전략을 바꿔 조회를 할 수 있다. 추가,서브 그래프란 무엇일까 해당과 같이 엔티티 그래..

OSIV가 True일 경우, 영속성 컨텍스트가 트랜잭션 범위를 넘어선 레이어까지 살아있다. API라면, 클라이언트에게 응답될 때까지, View라면, View가 렌더링 될때까지 영속성 컨텍스트가 살아있다. 쉽게 service에서 받은 lazy 로딩 전략의 엔티티를 controller에서 사용한다고 하자 controller에서 lazy 엔티티를 get하면, oslv가 true인 경우, 로딩을 하고, 프록시 객체가 실제 엔티티를 호출 쿼리가 나가고 값을 사용할수 있다. 하지만 lazy로딩일때, oslv가 false라고 가정하면, 영속성 컨텍스트가 닫혀버리면서, 지연로딩을 할수 없게된다. 기본 값이 true이긴한데, 단점이 존재한다. 영속성컨텍스트를 유지하는건 DB connection 도 계속 가지고있는 것이다..

스프링 데이터 JPA가 제공하는 Repository의 모든 메소드에는 기본적으로 트랜잭션이 적용되어 있다. 클래스,인터페이스,메소드에 사용가능, 메소드에 가장가까운 애노테이션이 우선순위가 높다. 기본적으로 Transactional(readOnly = true) 는 아무런 설정을 하지 않는 메서드에 적용된다. Transcational 옵션 -timeout설정 가능 -readOnly 인지 나타내는 flag 이값을 주면서 optimization 성능 최적화를 해줄 수 있는 여지가 생김 -가급적, 데이터 변경 할 일없으면, readOnly true로 해주는게 좋다. -> JPA에서 해당 readOnly로하게되면, 세션 플러시 모드가 매뉴얼로 설정이 되고 해당 설정이 되면 강제로 플러시를 하지 않는 이상 플러시를..

QueryDSL : JPQL 빌더로 동적 쿼리를 메소드로 구조화하여, 관리할 수 있도록 돕는 쿼리빌더 라이브러리이다. 사용 이유 : 문법이 sql문과 거의 유사, 문법 검색이 가능하다, string으로 쿼리를 작성하지 않아서, compile 시점에 에러를 잡아준다. 검색 조건 등 복잡한 동적 쿼리를 가능하게 해준다. 정리 QueryDsl 장점 - IDE 코드 자동완성 기능을 사용할수 있어 빠른개발이 가능하다. -문법적으로 잘못된 쿼리를 거의 허용하지 않는다. -도메인 타입과, 프로퍼티를 편리하게 참조할 수 있다. - 도메인 타입의 리펙토링 작업이 수월하다. 해당 관련 QueryDsl은 자세한 포스트를 통해 직접 실습을 해봐야겠다.

우선 Primitive type은 null을 허용하지 않고, wrapper class는 null을 허용한다. 만약 Long으로 하지않고, long으로 한다고 가정하면 값이 0인 경우 없는건지, 아니면 id 자체가 0인지를 알수 없다. Wrapper타입인 Long이나 Integer를 쓰면, id가 없는 경우, 확실히 null로 id가 없다는 것을 보장할 수 있다. 추가로, 이 id가 없다는 것으로 신규 객체인지 기존 객체인지 확인도 가능하다