DevLog 😶

🌱 들어가기 전너무 오랜만에 작성하는 블로그 글...! 최근에 사내에서 매우 많이 쓰이는 도메인에 대해서 리팩터링을 진행했었는데, 거기서 만났던 이슈들과 간단한 생각 기록을 블로그에 남기면 좋을 것 같아서 작성하고자 한다. 이미 팀 내에서 공유도 했었고, 동기들에게도 공유한 내용이기도 하고, 사실 별거 아닌 거라 그냥 간단하게만 정리할 예정이다. 🌱 문제 상황리팩터링을 진행하고자 한 도메인은 우리 팀에서 매우 중요한 비즈니스 도메인 객체 중 하나였고, 이미 안정적으로 잘 운영되고 있지만 굉장히 옛날부터 레거시로 내려오고 있던 객체였기 때문에 신규 입사자가 보기에 좋은 코드가 아니라는 생각이 들었다. 사내 도메인인 만큼 그대로 가져올 수는 없지만, 비슷한 느낌으로 아래와 같이 세팅을 진행해보았다.CREAT..

🌱 들어가기 전 옛날에 썼던 글인데, 요즘 블로그를 너무 안 쓴 것 같아서 오랜만에 올리는 글 😶 혼자 공부할 겸 작성한 글이었어서 다소 설명이 부족합니다...! 🌱 엔티티 소개 @Entity @EntityListeners(AuditingEntityListener.class) public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(nullable = false) @CreatedDate private LocalDateTime createdAt; @LastModifiedDate private LocalDateTime updatedAt; User 클래스는 사용자에 대한 엔티티이며, id..

🌱 들어가기 전 우리 팀의 경우 E2E 테스트 환경을 구축하기 위해서 @SpringBootTest를 통해 테스트 코드를 작성하고 있는데, 우리 팀의 팀원분이 아래와 같은 오류를 만나게 되었다. failed to lazily initialize a collection of role: co.kirikiri.domain.roadmap.RoadmapContent.nodes.values: could not initialize proxy - no Session 상황은 아래와 같다. (추후 코드로 더 잘 살펴볼 예정이다.) A라는 생성 API와 B라는 조회 API가 있을 때, 팀 내에서 기능을 세분화한 다음 각자 개발을 진행하다 보니 B를 개발하는 시점에 A라는 API가 없어, 통합 테스트 때 repository를 ..

🌱 들어가기 전 JPA에서 @OneToMany 단방향 매핑보다는 다대일 양방향 매핑을 권장한다는 말을 보았을 것이다. 하지만, 객체지향으로 코드를 설계하다 보면 다대일의 상황보다는 1인 엔티티를 기준으로 N인 엔티티를 조회하는 경우가 더 많고, (적어도 내 경험에서는 그랬다) N인 엔티티가 굳이 1인 엔티티에 대한 정보를 몰라도 됐던 적이 많았다. 그러다 보니 자연스럽게 일대다 단방향 매핑을 많이 사용했었는데, 왜 그랬던 것인지 궁금해서 나름대로 실험을 해보고자 한다. (ex. 게시글과 게시글 이미지의 관계에서, 게시글 이미지를 기준으로 게시글 정보를 찾아오는 것보다는 게시글을 기준으로 게시글 이미지 정보를 가져오는 게 더 많았음) 🌱 기본 엔티티 설계하기 @Entity class Board( @Id @..

🌱 JPA 기본 키 생성 전략 JPA에서 제공하는 기본 키 생성 전략은 크게 5가지로 나누어진다. - TABLE, SEQUENCE, IDENTITY, UUID, AUTO 각 전략에 대해서 하나씩 알아보도록 하자. 🌱 TABLE 💡 Indicates that the persistence provider must assign primary keys for the entity using an underlying database table to ensure uniqueness. - 데이터베이스 테이블을 사용하여 엔티티에 기본 키를 할당해야 한다. 💬 엔티티 설정 @Entity class User( @Id @GeneratedValue(strategy = GenerationType.TABLE) val id: Lon..

🌱 들어가기 전 지난 포스팅에서는 CascadeType.REMOVE에 대해서 중점적으로 알아봤었는데, 이번에는 orphanRemoval=true 옵션에 대해서 한 번 알아보자. 엔티티 세팅은 지난 번과 거의 동일하기 때문에 변화가 생긴 부분에 대해서만 따로 짚도록 하겠다. 🌱 엔티티 수정하기 이번에는 CascadeType.REMOVE 대신에 orphanRemoval=true를 적용하자. @Entity class Concert( @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0L, @Column(nullable = false) val name: String, @Column(nullable = false) val ticketLi..

🌱 들어가기 전 JPA를 공부하면서 CascadeType.REMOVE와 orphanRemoval = true 옵션에 대해서 어떤 차이가 있는지 제대로 인지한 적이 없는 것 같아서, 이번에 공부할 겸 여러 가지 테스트를 진행해보며 두 옵션의 차이를 공부해보았다. 결과적으로 말하자면 Cascade 옵션은 부모 엔티티와 자식 엔티티의 영속 상태를 관리하는 것이고, orphanRemoval은 조금 더 세부적으로 고아 객체에 대한 관리라는 생각이 들었다. 지금부터 여러 케스트를 테스트하며 하나씩 알아보자. 🌱 엔티티 세팅하기 1:N 관계를 담당해줄 '콘서트' 엔티티와 '콘서트 티켓' 엔티티를 생성하였다. 둘 사이의 관계는 양방향으로 설정하였으며, 하나의 콘서트는 여러 개의 콘서트 티켓을 보유할 수 있도록 설계하였..

🌱 문제 상황 페어 프로그래밍을 진행하면서, 분명 테스트 코드 각각을 실행했을 때는 잘 돌아갔는데 전체를 실행하니까 다음과 같은 오류를 만났었다. Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSourceScriptDatabaseInitializer' defined in class path resource [org/springframework/boot/autoconfigure/sql/init/DataSourceInitializationConfiguration.class]: Invocation of init method failed; nested exception is ..

- 지난 9월에, 회사에서 사이드 프로젝트로 JPA를 활용한 게시판 서비스 개발을 진행했었는데, 쿼리 튜닝을 진행하다가 내 마음대로 쿼리가 나가지 않는 걸 볼 수 있었다. - 당시 모델의 구조는 대략적으로 이렇다. 기본적인 게시판 엔티티이다. @Table(name = "tb_board") @Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Board extends BaseEntity { @Schema(description = "게시글 번호", required = true) @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long boardNo; @S..