본문 바로가기

개발일지

 (17)
JPA에서의 일급 컬렉션 적용 엔티티를 다시 값 타입 컬렉션으로 전환 바로 이전 포스트에서 값 타입 컬렉션을 엔티티로 승격시킨바 있다. 그 이유는 이전 포스트에도 설명했지만 추후 수정이나 추적의 여지가 있기에 해당 부분에 대한 변경을 진행해보았다. 물론, 태그라는 특성 자체가 수정이나 추적의 여지가 큰 건 아니지만 한 번 진행해본 부분이였다. 해당 부분을 수정한 뒤, 협업하는 팀원과 함께 논의를 거쳐 요구사항을 더 명확히 하기로 하였다. 그 결과, 태그 자체를 수정하는 로직은 존재하지 않으며 수정을 거치기 위해서는 단순 삭제 후 새로운 것을 추가하는 방향이며 태그를 추후 업데이트하고 싶다면 업데이트된 태그들을 담은 리스트로 기존 리스트를 대체하는 것이였다. 이 요구사항을 정리해보자. 수정은 불필요하다. 태그 요소들의 변경은 리스트 자..
값 타입 컬렉션 ➡ 엔티티 값 타입 컬렉션을 엔티티로 그전에 이를 적용하게 된 계기부터 살펴보자. 이전 포스트에서 태그에 대한 부분에 대해 @ElementCollection 어노테이션을 통해 태그들을 값 타입 컬렉션으로 관리해주었다. 나는 태그에 관한 부분에 대해 값 타입 컬렉션에서 엔티티로 승격하기로 한 두 가지 이유가 존재했다. ​ 첫 번째는 태그에 대한 요구사항의 변화에 유연하게 대처하고 싶었다. 태그 자체를 값 타입인 String 타입으로 저장하다보니 실제로 변경되거나 삭제되면 더이상 추적할 수 없고 그대로 다른 String으로 변하거나 삭제되어버린다. 추후 태그 자체의 수정을 가능하게하고 추적이 가능하게 할 수 있기 때문에 이에 대한 부분이 생긴다면 더 이상 값 타입으로 유지할 수 없고 엔티티로 승격해야하기에 미리 이 부..
@ElementCollections 사용기 값 타입 컬렉션 사용기 (feat. @ElementColletion) 이번에 값 타입 컬렉션을 사용하게 되었다. 값 타입 컬렉션이란 컬렉션에 값 타입을 담는 것을 의미하는데 값 타입이라는 것이 정확히 무슨 뜻인지에 대해서 알아보자. 값 타입은 흔히 엔티티와 많이 비교된다. 먼저, 우리에게 익숙한 엔티티에 대해서 먼저 알아보자. 엔티티는 우리가 흔히 @Entity로 정의하는 객체이며 @Id라는 어노테이션으로 정의한 PK(식별자)를 통해 계속적으로 추적이 가능하다. 하지만, 값 타입은 식별자라는 개념이 존재하지 않아 추적이 어렵다. 값 타입은 흔히 우리가 사용하는 Integer, String과 같은 자바의 원시 타입과 같은 존재로 우리가 흔히 사용하는 객체와 달리 공유에 안전하고 사이드 이펙트가 발생하지 않..
@Embeddable 활용기 @Embeddable 이번 프로젝트에서 엔티티를 구성하는데 있어 @Embeddable을 활용하였다. 이번에 이를 활용하면서 임베디드 타입을 언제 활용하면 좋은지, 어떤 장점이 존재하는지 좀 더 자세하게 알게 되었다. 이를 이번 포스트에서 정리해보려고 한다. 먼저, 사용한 배경에 대해 먼저 설명하려고 한다. 스터디 커뮤니티에서 스터디라는 엔티티를 구성하기 위한 다양한 요소가 존재했다. 스터디 작성자 스터디 제목 스터디 태그 스터디 썸네일 스터디 관련 학과 스터디 시작 일자 스터디 종료 일자 스터디 모집 일정 스터디 진행 여부 스터디 진행 방식 적어도 위와 같은 요소들을 포함해야했다. 수 많은 요소들이 존재하는데 복잡한 현실 세계 속에서 이를 조금 더 추상화해보기로 했다. 그래서 공통 요소로 추출할 수 있다..
Page, Slice에 대해 Page, Slice 오늘 다룰 포스트는 Page와 Slice이다. 우리는 흔히 어떤 웹을 돌아다녀도 페이징을 처리한 부분을 자주 찾아볼 수 있다. 우리가 개발을 하면서 구글링을 진행할 때 하단 부분을 바라보면 역시 페이징 처리되어 검색 페이지들이 나열되어 있는 모습을 확인할 수 있다. 이렇게 페이징을 처리하는 이유에 대해서 먼저 알아보자. 우리가 수 많은 데이터가 존재한다고 했을 때, 페이징을 처리하지 않고 모든 데이터들을 한 번에 뿌려준다면 어떻게 될까? 해당 데이터를 DB로부터 가져오는데 엄청난 시간이 소요될 것이다. 그 뿐 아니라, 해당 데이터 자체를 들고 있어야 하기에 엄청난 메모리의 소비가 존재할 것이다. 또한, 사용자들이 해당 게시물들을 모두 보게 하게끔 만들기에 용이하지 못하다. 그래서 우..
Cascade vs @Delete Cascade vs @OnDelete 이번 포스트는 이전에 다루었던 Cascade의 연장선이다. 이전에 언급했던 것처럼 생명주기를 공유하는, 어느 한 엔티티의 생명주기에 의존하는 엔티티들이 존재할 경우 Cascade를 사용하면 좋다고 언급했다. 그 이유는 프로젝트 - Cascade의 오해 (tistory.com)에 설명해놓았지만 간단히 다시 살펴보겠다. 어떠한 게시판이 존재한다고 가정하자. 우리가 흔히 잘 알고있듯이 게시판에는 여러개의 게시글, 그 안에 여러개의 댓글이 존재한다. (추천 또한 존재할 수 있다.) 만약, 게시판이 존재한다면 어떻게 될까? 일반적인 경우에는 게시판이 제거됨과 동시에 그 안에 존재하는 게시글, 댓글 (혹은 추천)이 모두 제거될 것이다. 왜냐하면 그들은 게시판의 생명주기에 의존하..
Cascade의 오해 Cascade의 오해 나는 현재 스터디 커뮤니티에 대한 프로젝트를 진행 중에 있다. 위 주제에 대해 살펴보기 전에, 간단하게 요구사항에 대한 부분을 살펴보자. 회원은 스터디에 가입, 생성, 수정, 삭제할 수 있다. 회원은 여러 스터디에 참여할 수 있다. 회원은 스터디에 가입하기 위해 신청을 진행한 후, 스터디 생성자 혹은 관리자가 수락한다면 가입할 수 있다. 스터디 생성자 혹은 관리자는 스터디 신청자를 거절할 수 있다. 스터디는 각 스터디 게시판, 게시글에 대한 조회, 생성, 수정, 삭제가 가능하다. 이 요구사항에 맞게 도출된 ERD를 살펴보면 다음 그림과 같다. 물론, 이 요구사항 이상의 사항들을 ERD에서 포함하고 있지만 이 주제에 대해 다루기에는 충분하기에 생략하겠다. 나는 이러한 부분에 대한 연관..
알림 기능을 구현해보자 - SSE(Server-Sent-Events)! 시작하기에 앞서 이번에 개발을 진행하면서 알림에 대한 요구사항을 만족시켜야하는 상황이 발생했다. 여기서 말하는 알림이 무엇인지 자세하게 살펴보자. A라는 사람이 스터디를 생성했고 B라는 사람은 어느 스터디에도 가입하지 않은 정규 회원이라고 가정하자. A라는 사람은 스터디 생성자일 것이고 B라는 사람은 위에서 언급했듯이 단순 정규 회원이다. B라는 사람은 어느 스터디에도 가입할 수 있고 A라는 사람이 생성한 스터디에 가입 신청을 하여 스터디에 가입할 수 있다. A라는 사람은 항상 웹페이지에 들어가지도 않을 것이고 항상 스터디 관리페이지에 들어가지 않을 것이다. 이런 상황속에서 A라는 사람은 어느 누군가(현재 상황에선 B라는 사람)가 스터디에 지원을 했는지 알고 이를 승인하거나 거절해야할까? 바로 가장 쉬운..

티스토리툴바