DevBoi

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..

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

엔티티 타입 @Entity로 정의하는 객체 데이터가 변해도 식별자로 지속해서 추적가능 예_ 회원 엔티티의 키나 나이값을 변경해도 식별자로 인식가능 값 타입 int,Integer,문자열 처럼 단순히 값으로 사용하는 자바 기본타입이나 객체 식별자가 없고, 값만 있으므로 변경시 추적불가 예_숫자 100을 200으로 변경하면 완전히 다른 값으로 대체 된다. -값타입_ 기본값 타입 -자바 기본타입 -int,long -> 공유가 되지 않는 객체 -래퍼 클래스 -Integer,Long -> 공유가 가능하지만, 변경되면 안된다. -String -값타입_임베디드 타입 JPA에서 임베디드한, 데이터 값을 이런식으로 컬럼으로 가질수있다. 이렇게하면, 하위 속성들이 별도 컬럼으로 생성이된다. 이렇게 사용하면 재사용 성이 높고..

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

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

@Configuration 스프링에서 설정 클래스를 선언하는 어노테이션이다. 우선 스프링 빈을 만드는 방법은 @Bean, @Configurtaion, @Component 3가지 어노테이션을 사용하면 된다. Configuration을 클래스 파일에 달게 되면, 이 클래스는 빈등록하기 위한 파일이라는 것을 가시적으로 알려준다. @Configuration을 붙인 class를 java config파일이라고 생각한다면 @Configuration에 대한 클래스 파일 하위에 객체에 대한 return을 해주는 메소드에 빈을 해주면, ApplicationContext 중, AnnotationConfigApplicationContext는 JavaConfig클래스를 읽어 IOC와 DI를 적용하게 된다. 쉽게말하면, Conf..