아장아장거리면서 주책부리는 블로그

서브쿼리 쿼리안에서 사용되는 서브쿼리를 만들어 쓸 수 있다. (괜히 연산 하나 한 값을 가져와서 이걸 대입해서 뭐 어떻게 하려는거보단, 편할테니까???) 예를들면, Member의 age가 18살 이상인 사람들이 속한 팀들을 조회해오는 방식으로 처리될 수 있다. 서브쿼리에서 지원되는 함수는 Exists (서브쿼리) : 서브쿼리의 결과가 존재하면 참 All (서브쿼리) : 모두 만족하면 참 Any (서브쿼리) : 조건을 하나라도 만족하면 참 Some : Any와 동일 In (서브쿼리) : 서브쿼리의 결과중 하나라도 같은게 존재하면 참 Exists, In은 앞에 not을 붙여 사용할 수 있다. team1이라는 엔티티를 조회한다. 이게 멤버에게 존재한다면 참을 반환한다. 즉, team1이라는 인스턴스를 가지고 ..

조인 내부 조인, 외부 조인, 세타 조인등 모두 구현이 된다. (세타조인 : 관계도 없는 것들을 합쳐서, 여기에서 해당되는 부분들은 모두 찾아오는 것) ON절을 이용한 조인 조인 대상을 미리 필터링 한 상태에서 join을 이용한 쿼리문을 이용할 수 있다. (결국, 연산량을 줄일 수 있다) 연관관계가 없는 외부 조인을 시킬 수 있다. 이렇게 on을 이용한 join 쿼리문에서, 이렇게 team1인 팀들을 먼저 구해놓고, 그 중에서 member를 구하는 방식으로 처리될 수 있다. 이런식으로 연관관계를 사용하지 않는 쿼리문에서도 on을 통해 그냥 두 문자열을 비교해서 같은 것들을 전부 반환하라는 쿼리를 보낼 수 있다. 이 때에도 에러가 발생하지 않고, 쿼리문이 정상적으로 만들어져 보내지는 것을 볼 수 있다.

프로젝션 Select절에서 조회 대상을 지정하는 것. 엔티티, 임베디드타입, 스칼라 타입(숫자, 문자, 기본 데이터 타입) Select m from Member as m ~~; (엔티티) Select m.username, m.age from Member as m~~; (엔티티의 스칼라 타입) Select m.team from Member as m ~~; (연관관계의 엔티티) Select m.address from Member asm m ~~;(임베디드 타입) 전부다 조회 가능하며, select 뒤에 distinct를 넣어 중복을 제거할 수 있다. 조회를 해서 엔티티를 불러오는 방법은 알겠는데, 우리가 조회한 엔티티의 인스턴스를 수정하면 어떻게 될까? 이러한 코드를 실행했을 때, Select, update..

페이징 API .setFirstResult .setMaxReseult 이 두개로 다해먹는닫고 보면 된다. 대충 멤버를 100개 정도 복제시킨 후(?) 조회를 할 때, 첫 번째 인덱스를 0으로, 최대 개수를 10개로 잡아 리스트로 반환했을 때, 아주 잘나온다.

JQPL 객체지향 쿼리. 즉, 엔티티를 위한 쿼리이다. JPQL의 문법을 보면, 일반 sql문과 크게 다를게 없어 보인다는 생각도 든다. Select * from Member where Member.age > 18; (SQL) Select m from Member as m where m.age > 18; (JPQL) 정말 비슷하다. *인가 m인가 말고는 큰 차이가 보이지 않을 정도이다. 심지어 테이블명, 속성명에서 대소문자를 구분한다는 것도 동일하다. 차이점은, JPQL은 클래스명을 사용한다는 것이다. 특이점은, 별칭(Memer as m)이 쓰인다는 것이다. Count, sum, avg, max, min, group by, having, order by 등 모든 것을 다 쓸 수 있다. 이를 변수로 받을 ..

JPA에서 쿼리문을 만들어내는 방법은 엄청나게 다양하다. JPQL JPA Criteria QueryDSL 네이티브 SQL JDBC API 직접사용, MyBatis, SpringJdbcTemplcate 함꼐 사용 이렇게 다양한 방식이 있는데, 이에 대한 정리를 해보았다. JPQL 가장 단순한 조회 EntityManager.find() a.get().get() 개발을 엔티티 객체 중심으로 개발할 수 있다. 문제는, 데이터를 검색할 경우, 테이블을 기준으로 해야 한다. 이 부분을 우리가 개발할 때 사용했던, 객체를 기준으로 할 수 없을까? 모든 db 데이터를 객체화 시키면 성능의 문제가 생긴다. 이를 위해 객체 지향 JPQL이라는 객체 지향 쿼리문이 존재한다. JPQL = 엔티티를 대상으로 검색 SQL = 테..

JPA에서는 데이터 타입을 두가지로 만들어 저장한다. 엔티티 타입 데이터가 변해도 식별자로 계속 확인 가능. 데이터의 인스턴스가 변경되어도 식별자를 통해 이게 무슨 데이터인지 알 수 있다. 예) 나이를 먹어도 나이를 보고 아 이게 나이구나 라고 알 수 있다. 값 타입 Int, String처럼 단순값으로 사용되는 타입이나 객체 식별자가 없고 값만 있기 때문에 변경시 추적 불가능하다. 예) 26(하 2023년이제 이제...)을 보고 이게 나이인지(물론 난 알지) 뭔지 알 수 없다. 오늘 공부해본 값 타입에는 3가지가 존재한다. 기본값 타입(java에서 기본으로 제공해 사용할 수 있는 타입) 임베디드 타입(복합 값) 컬렉션 타입 (임베디드와 컬렉션은 JPA에서 설정해서 사용해야 한다. ) 기본값 타입 Stri..

Member라는 엔티티에서 이루어지는 도메인 로직에 대한 테스트들을 만들었다. 이 테스트를 정상적으로 수행하기 위한 코드를 만들어보아야 겠다. Member라는 도메인 로직을 짜면서 추가적으로 고민했던 부분은, 다른 도메인과 엮여 사용되어 다른 도메인, 다른 기능에 종속적이지 않게 하려고 했다. 외부에서 Member에 대한 데이터를 변경하는 기능을 수행하는 경우를 만들지 않도록, 도메인 내에서 모든 로직을 만들려고 했다. 이러한 점을 토대로, 회원가입 / 정보 수정 / 비밀번호 변경 기간 만기여부 확인의 기능을 만들었다. 회원가입 일단 회원가입 로직부터 정리를 해보았다. 일단 필요한 경우는 이메일 형식이 올바르지 않으면 예외처리 비밀번호 2번 입력이 서로 일치하지 않으면 예외처리 예외가 없다면 인스턴스 초..

Member에 대한 테스트를 만들어보아야 겠다. 일단, Member 생성자에 RegisterRequestDto를 넣을 것이다. 그러기 위해, 테스트를 위한 RegisterRequestDto를 생성하주자. private RegisterRequestDto makeTestRegister(){ return new RegisterRequestDto("username", "nickname", "email@email.com" , "password", "password"); } AllArgsConstructor로 모든 인스턴스를 넣은 Dto를 만들었다. 이를 @Builder를 이용해 조금 더 깔끔하게 만들어보았다. @AllArgsConstructor @Data @Builder public class RegisterRe..

이전에 멤버에 대한 구상을 해둔 상태이다. 이에 맞는 멤버를 만들어보아야 겠다. @Entity @Data @AllArgsConstructor @NoArgsConstructor @Builder public class Member extends BaseEntity { @Column(name = "MEMBER_USERNAME") private String username; @Column(name = "MEMBER_NICKNAME") private String nickname; @Column(name = "MEMBER_EMAIL") private String email; @Column(name = "MEMBER_PASSWORD") private String password; @Column(name = "MEMB..