Hello backEnd

querydsl에서 다대다 구현하기. 일대다-다대일(feat. Result Aggregation) 보통 다대다 매핑을 할 때에는 일대다 - 다대일로 매핑하도록 시킨다. 이 이유는 어차피 JPA에서 만든 후에 이를 처리해주기 위한 중간 테이블을 생성하게 된다. 근데 이 테이블을 사용하는 동안 정체모를 쿼리가 발생할 가능성이 있다. 중간 테이블에도 메타 데이터 등의 추가 쿼리가 필요할 수 있는데, 이를 다대다에서는 개발자가 넣어줄 수 없다. 암튼 그래서... 일대다 다대일로 하는데, 여기서 하나의 파트에서 반대 파트의 데이터를 가져오는 방법을 살펴보도록 한다. 상황 먼저 프로젝트 밈위키 에서는 대충 뭐 이런 느낌으로 "밈 - 태그" 를 갖고 있다. 이는 생각해보면 이렇게 밈과 태그가 다대다로 묶여 있어서 밈..

save랑 saveAll(feat. Transactional) Spring Data JPA를 통해 다양한 쿼링을 쉽게 해줄 수 있다. 근데 만약에 여러 insert를 해줘야 하는 경우가 있다면 어쩔까?? 상황 일단 Spring Data JPA에 대해 안다고 가정한다. 여러 값을 저장할 때에 save방식 넣을값들.forEach( index -> 저장레포지터리.save(index) )이거랑 saveAll방식 저장레포지터리.saveAll(넣을값들);의 차이가 뭘까?? save 일단 save를 한번 본다. saveAll 이제 saveAll을 본다 뭐가 다른겨? 사실 saveAll을 보면 최초에 Transactional 어노테이션 실행 해당 함수 내에서 save함수 실행 저 save는 save함수임 이렇게 간다...

값 타입 기본값 타입 임베디드 타입(복합 값 타입) 값 타입과 불변 객체 값 타입의 비교 값 타입 컬렉션 기본값 타입 JPA는 데이터 타입을 최상위 레벨로 볼 때 두가지로 분류한다. 엔티티 타입 @Entity로 정의하는 객체 데이터가 변해도 식별자를 통해 지속해서 추적이 가능하다. 값 타입 int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체 식별자가 없고 값만 있으므로 변경시 추적이 불가능하다. 값 타입의 분류 기본값 타입 자바 기본 타입(int, double) 래퍼 클래스(Integer, Long) String 임베디드 타입(enbedded type, 복합 값 타입) 컬렉션 타입 기본값 타입 생명 주기를 엔티티에 의존한다. 즉 엔티티를 삭제하면 기본값도 삭제된다. ..

디프만 프로젝트에서 댓글 관련 API중 하나를 담당했는데, 해당 내용은 어떤 맥주를 통해 이곳에 작성된 모든 기록들을 받아오고, 동시에 저장된 맛(최대 3개)를 가져와 보여준다. 그리고 여기 페이징을 적용한다. 였다. 즉 이 경우 기록 -> 맛을 가져올 때 일대다 조인이 생기게 된다. 맥주를 통해 기록을 가져옴(여기서 N개의 기록을 가져옴) 해당 기록에 있는 맛태그를 가져옴(최대 3개의 맛태그) 맛태그를 통해 맛을 가져옴(다대일) 2, 3번의 로직을 수행할 때에 문제가 여러개 생기게 된다. 먼저 일대다 조인의 경우 페치 조인만으로 페이징을 할 수 없다. 알다시피 일대다 조인을 페치조인하면 동일한 데이터가 여러 번 출력되어 데이터가 뻥튀기된다!! 그리고 비효율적인 쿼리가 생성되게 된다. 하나의 기록마다 맛..

실무에서 매우 중요하다. SQL의 조인 종류에 해당하지는 않는다. JPQL에서 성능 최적화를 위해 제공하는 기능이다. 연관된 엔티티나 컬렉션을 SQL한 번에 조회하는 기능. join fetch 명령어 사용 예를 들어 회원을 조회하면서 연관된 팀을 함께 조회하려 한다(SQL한번에) select m from Member m join fetch m.team -> SELECT M., T. FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID=T.ID 아래와 같이 inner join을 사용하여 Team이 있는 member들을 가져온다고 가정한다면 JpaMain public class JpaMain { public static void main(String[] args){ EntityMa..

프록시 JPA에서는 검색할 때에 em.find()말고도 em.getReference()라는 메소드를 제공한다. 이 em.getReference()는 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체를 조회한다. -> 즉 DB에 쿼리가 나가지 않은 상태로 객체를 조회한다. 코드를 통해 확인해 보자면 Member클래스에서 필요없는거 없애기 @Entity public class Member extends BaseEntity { @Id @GeneratedValue @Column(name = "MEMBER_ID") private Long id; @Column(name = "USERNAME") private String username; public Long getId() { return id; } public..

Spring Data JPA를 통한 CRUD방법에 관하여..(feat 변경감지) Spring Data JPA를 사용한 CRUD방법을 구현하면 어떻게 하나? 조회(Read) find나 get을 사용한다. 이 둘의 차이는 여기서 알아보자 저장(Create) save를 사용한다. 이 save에 관해 조금 후에 다시 서술한다. 삭제(Delete) delete를 사용하거나, 실제로 데이터를 삭제하고 싶지 않으면 soft delete를 하면 된다. 이제 변경(Update)를 한다면? Update방식 위에서 데이터 저장에 사용된 save에 대해 먼저 알아보자 얘 코드를 살펴보면 /* * (non-Javadoc) * @see org.springframework.data.repository.CrudRepository#s..

Spring Data JPA에서 ID를 통하여 어떤 엔티티를 조회하고 싶을 때, 우리는 getById나 findById를 사용한다. 둘 간에 어떤 차이가 있을까?? getById @Override public T getById(ID id) { Assert.notNull(id, ID_MUST_NOT_BE_NULL); return em.getReference(getDomainClass(), id); } getById의 내부를 살펴보면 이렇게 나온다. 이 getById는 em.getReferecnce를 이용해서 엔티티를 조회..하는데, 사실 이거는 엔티티가 아니라 프록시를 반환한다는 것이다. 즉, getById를 통해 바로 DB에 검색하는게 아니라, 이를 실제로 사용할 때에 DB에 접근한다는 것이다. 한마디로..

DB의 삭제 구현 방법은 두가지가 있다. Soft Delete 데이터를 실제로 삭제하지 않고, 삭제 flag를 변경하는 방법이다. Hard Delete 실제로 데이터를 삭제하는 방법이다. 실제로 서비스를 구현할 때에는 Soft Delete를 자주 사용한다. 하지만 Spring Data JPA에서 이 Soft Delete를 구현할 때에는 주의해야 할 점이 다수 있다. 만약에 한꺼번에 많은 데이터를 삭제하는 경우가 생긴다면 어떨까?? 이러한 Bulk연산에서 Soft Delete를 사용할 때에 여러 번의 쿼링이 진행되게 될 것이다. 이를 해결하기 위해서 @SQLDelete어노테이션과 JPA에서 제공하는 deleteAllInBatch를 사용할 수 있다. @SQLDelete JPA에서 기본으로 삭제는 Hard D..

JPA란 Comment 과거에는 SQL을 하나씩 작성하던 것을 JPA가 나타난 후부터는 코드로 작성할 수 있게 해 주었다. 그럼 JPA가 그에 맞는 sql을 실행해 준다. 속도, 생산성과 유지보수 등에서 훨씬 빨라졌다. 다만 난이도가 어렵다. 실무에서는 JPA를 사용하면 굉장히 어렵다. JPA는 다른 것들에 비해 객체와 테이블을 잘 설계하고 매핑을 해야 한다. JPA의 내부 동작 방식을 모르고 쓰는 경우가 많다. JPA가 어떤 SQL을 만들어 내고, 언제 실행하는지 이해해야 한다. 기존 SQL을 사용하는 문제점 개발 언어는 주로 객체지향 언어이다 + DB는 주로 RDB(관계형 DB)를 사용한다 => 즉, 객체를 관계형 DB에 관리한다. SQL중심적인 코딩의 문제점 일단 지루함. 코드 완성 후 변경사항이 ..