영호

들어가면서 이번 글에서는 프로젝트를 진행하며 엔티티 구조를 변경해 로직 복잡성을 낮추고, 쿼리를 개선한 경험을 작성하려고 합니다. 상황 및 엔티티 구조 설명 상황 설명 저희 프로젝트는 개인 카페의 쿠폰을 한 곳에서 관리해주는 서비스 입니다. 여기에 더불어 카페 사장님은 쿠폰의 디자인, 쿠폰에 찍히는 스탬프의 위치를 모두 커스텀 할 수 있습니다. 그리고 발급된 쿠폰은 발급 당시의 이미지 정보를 토대로 보여지게 됩니다. A쿠폰 발급 후 사장님이 카페의 쿠폰 이미지를 변경해도 A쿠폰은 발급 당시의 이미지로 보여집니다. 즉, 쿠폰은 발급 당시 이미지, 스탬프 위치 정보를 적용합니다. 엔티티 구조 설명 위 요구사항을 만족하기 위해 카페 별 쿠폰 정보를 저장하는 복사 테이블을 만들었습니다. 그 이유는 당시 저희는 ..

들어가면서, 우테코에서 프로젝트를 진행하면서 엔티티 상속 구조를 JOINED 전략을 사용한 적이 있었는데, 이 과정에서 경험한 상속 구조 사용 시 주의점에 대해 간략하게 정리할 예정이다. 상속 구조를 적용한 상황 우리 서비스는 2종류의 회원이 있다. 전화번호를 통해 가입한 임시회원 실제 우리 서비스에 접속해 회원가입을 한 정식 회원 그리고 임시회원인 상태에서도 여러 쿠폰을 발급 받을 수 있다. 결론 결론부터 빠르게 정리하자면 abstract 클래스의 dtype 을 변경할 일이 있을 때는 사용하기 부적절한 것 같다. 위에 작성한 dtype 변경 상황을 예로 들자면, 임시회원 상태에서 서비스에 접속해 회원가입 하면 해당 고객은 정식 회원 타입으로 변경해야 한다. 이 과정에서 customer 테이블의 dtyp..

들어가면서, 프로젝트 중 spring data jpa 의 deleteAll() 을 사용할 때 매우 많은 쿼리가 발생했는데, 그 이유와 해결방안에 대해서 작성할 예정입니다. 아래 사진과 같이 Coupon, CouponDesign 이 연관관계가 설정되어 있고, cascade.REMOVE 옵션도 설정되어 있는 상태에서 여러개의 Coupon 을 지우는 상황이다. Coupon @Entity public class Coupon extends BaseDate { @Id @GeneratedValue(strategy = IDENTITY) private Long id; private Boolean deleted = Boolean.FALSE; @ManyToOne(fetch = LAZY) @JoinColumn(name = "..

들어가면서, 우아한테크코스 레벨3를 진행하면서 모든 layer에 대해 테스트코드를 작성했다. 그 중에서도 service레이어 테스트는 @SpringBootTest, @Transactional을 이용한 테스트를 진행했다. 그 이유는 우리의 비즈니스 로직 수행 후 DB에 알맞게 데이터가 들어갔는지 확인하고 싶었기 때문이다. 하지만, RestAssured를 통한 인수테스트를 작성하는 상황에서 service레이어의 통합테스트가 필요한지에 대해 고민하다가 service레이어의 테스트 코드를 수정한 과정에 대해 기록하겠습니다. 개선 이유1 service레이어의 관심사가 무엇인지 생각해봤습니다. service레이어는 entity의 메서드, repository의 호출을 통해 요구사항에 맞는 비즈니스 로직을 수행하는 것..

들어가면서, repository단위 테스트를 작성하면서 save한 엔티티의 createdAt이 필요했는데, 해당 값이 계속 null인 문제를 해결한 과정입니다. 현재 createdAt은 @EntityListeners(AuditingEntityListener.class) 을 이용해 생성하고 있습니다. 문제 코드 @DataJpaTest class CafePolicyRepositoryTest { @Autowired private CafePolicyRepository cafePolicyRepository; @Test void 특정_시간보다_이후에_생성된_카페_리워드_정책이_없으면_빈_리스트_반환() { Cafe savedCafe = cafeRepository.save(new Cafe()); CafePolicy ..

들어가면서, 관계형 데이터베이스를 사용하면서 각각의 데이터를 식별하는 기본키는 중요한 개념이다. 데이터베이스마다 기본 키를 생성해주는 방식은 다양하다. 그래서 JPA에서도 다양한 방식에 대응하기 위해 4가지 정도의 기본 키 생성전략이 존재하는데 각각의 특징에 대해서 정리하려고 한다. AUTO 해당 전략의 경우 id로 사용하려는 필드의 타입, 사용하는 데이터베이스에 따라 전략을 '알아서' 선택해주는 방식이다. 우선, id로 사용하려는 필드 타입의 경우 2가지가 있다. UUID, Numeric(Integer, Long)이 있다. UUID를 사용하는 경우 JPA는 UUIDGenerator를 이용해 기본 키를 생성해준다. 그리고, Numeric의 경우 SequenceStyleGenerator에 의해 기본 키가 ..