공대키메라

내부조인 : SELECT m FROM Member m [INNER] JOIN m.team t 외부조인 : SELECT m FROM Member m LEFT [OUTER] JOIN m.team t 세타 조인 : select count(m) from Member m, Team t where m.username = t.name 1. 조인 대상 필터링 예) 회원과 팀을 조인하면서, 팀 이름이 A인 팀만 조인 JPQL : SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A' 실행된 SQL : SELECT m.*, t.* FROM Member m LEFT JOIN Team t on m.TEAM_ID = t.id and t.name = 'A' 2. 연관관계 없는..

JPQL(Java Persistence Query Language) JPQL은 객체지향 쿼리 언이이다. 따라서 테이블을 대상으로 쿼리하는 것이 아니라 엔티티 객체를 대상으로 쿼리한다. JPQL은 SQL을 추상화해서 특정 데이터베이스 SQL에 의존하지 않는다. JQPL은 결국 SQL로 변환된다. 근데 위치 기반 쓰면 안됀다! 이름을 적는것은 위치가 바뀌어도 버그가 안생김! 무조건 이름 기반으로 작성한다 프로젝션 SELECT절에 조회할 대상을 지정하는 것 프로젝션 대상 : 엔티티, 임베디드 타입, 스칼라 타입(숫자, 문자등 기본 데이터 타입) SELECT m FROM Member m => 엔티티 프로젝션 SELECT m.team FROM Member m => 엔티티 프로젝션 SELECT m.address F..

이제 객체 지향 쿼리에 대해 알아볼것임! JPQL jpa Criteria QueryDSL 네이티브 SQL JDBC API 직접 사용, MyBatis, SpringJdbcTemplate함께 사용 JPQL 소개 가장 단순한 조회 방법 1. EntityManager.find() 2. 객체 그래프 탐색(a.getB().getC()) JPA를 사용하면 엔티티 객체를 중심으로 개발 문제는 검색 쿼리이다! 검색을 할 떄도 테이블이 아닌 엔티티 객체를 대상으로 검색 모든 DB 데이터를 객체를 변환해서 검색하는 것은 불가능 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 조건이 포함된 SQL이 필요 그래서... JPA는 SQL를 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다 SQL과 문법이 유사하다..

값 타입 : 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 함 int a = 10; int b = 20; public class ValudMain{ public static void main(String args){ int a = 10; int b = 10; System.out.println("a == b " + (a == b)); Address address1 = new Address ("city", "street", "10000"); Address address1 = new Address ("city", "street", "10000"); System.out.println("address1 == address2 : " + (address1== address2)); } } 위에 결과는 알아서..

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다! 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다. 코드를 예를 들어 설명해 보면 두개의 Member 가 하나의 address 를 참조하고 있는 상황인데 member1과 member2에 같은 address를 삽입하고 member2의 address값을 바꾸면 오잉? 연결되어 있는 member1의 값도 바뀌게 된다. 기존의 의도는 member2에 저장된 address의 값만 바꾸고 싶었는데 member1도 바뀌는 버그가 발생하는 것이다! 복잡한 경우에는 이 오류를 찾기 정말 힘들다고 한다. 이를 방지하기 위해서는 새로운 address객체를 하나 더 생성해서 그것을 이용해 member2의 값을 바꿔야 한다. package helloj..

소유자가 하나일 때는 casecaseType.ALL로 설정해서 관련된 테이블에 정보를 다 넣어도 상관이 없음. 근데 이제 하나의 테이블만 연관된 것이 아닌 여러개가 하나의 테이블에 접근하고 소유자가 하나가 아닐 때는 사용하면 안됌~ => 중구난방으로 쿼리가 들어감 ㅠㅠ 예시) @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL,orphanRemoval = true) private List childList = new ArrayList(); 기본값 타입 JPA는 두개의 데이터 타입으로 분류가 가능하다 1. 엔티티 타입 @Entity로 정의하는 객체 데이터가 변해도 식별자로 지속해서 추적 가능 예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능..

이걸 햇다옹! 아 귀찮아 ㅎㅎ 프록시 Member를 조회할 때 Team도 함께 조회해야 하나? 이에 대해 해결하려면 프록시를 제대로 이해해야 한다! 프록시의 특징 실제 클래스를 상속 받아서 만들어짐 실제 클래스와 겉 모양이 같다. 사용하는 입장에선느 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다(이론상...) 프록시 객체는 실제 객체의 참조(target)를 보관 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출 즉시 로딩과 지연 로딩 지연 로딩 LAZY를 사용해서 프록시로 조회 이것은 이론적인것이고 실무에서는 무조건 극소수를 제외하고 무조건 지연로딩으로 바른다! JPQL Fetch 조인이나, 엔티티 그래프 기능을 사용해라! 즉시 로딩은 상상하지 못한 쿼리가 나간다.

그러니까 공통되는 것들은 별도의 Class를 빼서 넣어주면 됨

이 부분은 편히 공부해도 된다! 그냥 보라네! 이렇게 쓰면 안된다고 한다. @ManyToMany 사용을 해서 지정 가능 근데 들어가기 전에 알아야 할 것은 쓰지 말라는거임 ! ㅋㅋ 여기서 테이블에 관한 이야기인데 ORDER 테이블으 Member_ID 랑 Product_ID를 참조해서 복합키로 사용하고 있다. 처음 설계상에서는 이렇게 하면 깔끔하고 장점이 많은데 어플리케이션이 이제 업데이트가 되고 수정이 되는 과정에ㅐ서 받아온 FK가 변동될 수 도 있다. 그렇기에 ORDER 테이블에 그 테이블 만의 PK를 별도로 생성을 해주면 후에 관리를 하는데 유용하다고 해서 Teacher는 이렇게 많이 쓴다고 한다. 그러면 이제 실전 예제 3으로 한번 넘어가보자! 실전 예제 3 - 다양한 연관관계 매핑 근데 그냥 보고..

고려사항 3가지 1. 다중성 (@OneToMany, @ManyToOne, @OneToOne, @ManyToMany) 2. 단방향, 양방향 3. 연관관계의 주인 package jpabook.jpashop.domain; import javax.persistence.*; import java.util.ArrayList; @Entity public class Member { @Id @GeneratedValue @Column(name = "MEMBER_ID") private Long id; @Column(name = "USERNAME") private String name; @ManyToOne @JoinColumn(name = "TEAM_ID") // 우선 ManyToOne 그러니까 //Member가 여러명이고 ..