EntityManagerFactory에서 고객이 요청할때마다 EntityManager를 생성하고,이 엔티티매니저는 내부적으로 DB의 커넥션을 사용하여 DB를 사용한다.
객체지향 설계의 목표는 자율적인 객체들의 협력 공동체를 만드는 것이다. 객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력관계를 만들 수 없다.
관계형 데이터베이스는 상속관계가 없지만, 슈퍼타입 서브타입 관계의 모델링 기법이 객체 상속과 유사하다. 즉, 상속관계 매핑은 객체의 상속 구조와 DB의 슈퍼타입 서브타입관계를 매핑하는 것이다.
실제 클래스를 상속받아 만들어져서, 실제 클래스와 겉모양이 같다. 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지않고 사용하면 된다. 프록시 객체는 실제 객체의 참조(target)을 보관하고있다.
Spring Data JPA의 delete 와 deleteById 의 차이는 무엇인지 성능상으로도 차이가 있는지 궁금해서 찾아본 내용입니다. 먼저 결론부터 말하면 delteById 는 findById + delete 가 합쳐진 메서드이다.
먼저 Member 엔티티는 Board 엔티티를 일대다 관계(OneToMany)로 매핑,Board엔티티는 Member엔티티를 다대일 관계(ManyToOne)로 매핑하여 양방향 매핑된 상태이다.
일대다 조인에서는 DB가 뻥튀기 되서 최적화하기 어려워진다.최적화에 대해 더 많이 고민해야한다. 일다대에서 일(1)을 기준으로 페이징을 하는 것이 목적이지만 데이터는 다(N)를 기준으로 row 가 생성된다.
SQL 쓰듯이 데이터를 한줄밖에 못넣기 때문에, 일대다 관계인 컬렉션은 생성자 파라미터로 데이터를 넣을 수 없어서, 컬렉션을 제외하고 이전과 동일하게 DTO로 조회한다. 이후 반복루프를 돌면서 컬렉션도 동일하게 DTO로 조회 후 데이터를 채워준다.
cascade - 특정 엔티티를 영속 상태로 만들때 연관된 엔티티도 함께 영속상태로 만들고 싶을때 사용한다. 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐 영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없다
JPA의 변경감지 (DirtyChecking) JPA에는 수정관련된 메서드가 존재하지 않는다. JPA를 통해 데이터를 수정하려면, Entity를 조회하여 조회된 Entity의 데이터를 변경하면 DB에 자동으로 반영되는 기능을 Dirty Checking이라고 한다.
프록시는 id값만 가지고 있고 target이 null로 된, 내부에는 비어있는 가짜 객체이다. 실제 클래스를 상속받아 만들어져서, 실제 클래스와 겉모양이 같다. 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지않고 사용하면 된다.