전체 글
-
[JPA] 양방향 연관관계개발/Java 2023. 4. 18. 00:58
연관 관계 객체가 아닌 DB 테이블의 경우 FK를 통해서 그 관계를 바로 파악할 수 있다. 하지만 이를 객체 관점에서 본다면 FK가 선언된 자식 엔티티 객체와 부모 엔티티 간의 관계를 함께 표현해야 한다. 이런 관점에서 양방향 연관관계를 아래와 같이 선언할 수 있다. 늘 양방향으로 선언된 관계가 정답일 수는 없지만 양방향으로 선언된 구조가 어떤 형태이고 어떤 문제가 발생할 수 있는지 알아보자. 양방향 연관 관계와 그 주인 // Member.java @ManyToOne @JoinColumn(name = "TEAM_ID") private Team team; // Team.java @OneToMany(mappedBy = "team") private List members = new ArrayList(); 우리..
-
[OpenStack] Nova-Compute IncompatibleObjectVersion 해결하기메모/트러블 슈팅 2023. 3. 29. 19:38
개요 원래 1개의 데스크탑, 3개의 라즈베리파이에 우분투를 설치하고 개인 서버로 활용하고 있었다. 솔직히 데스크탑은 공부용, 개발서버용 정도로 쓰고 있었는데 라즈베리파이가 놀고 있는게 맘에 좀 걸렸다. 그러면서 또 여러 문제가 생겼는데 개인 서버가 있으니 클라우드를 활용하는 빈도가 현저히 적어졌다는 거다. 솔직히 돈도 돈 때문에 안쓴거긴 하지만... 그러다가 오픈스택을 함 올려볼까 싶었다. 그래서 고민 끝에 윈도우 데스크탑을 밀고 우분투 서버를 설치했다. 결과적으로 컴퓨팅 노드, 컨트롤 노드로 쓰일 데스크탑 서버 2대와 스토리지 노드로 쓰일 라즈베리파이 3대가 생겼다. 이걸 클러스터링해서 어떻게 오픈스택을 잘 올려보려고 했다. 문제 발생 설치 과정이나 개념 정리는 다음에 한번에 적어보기로 하고... Ke..
-
[Spring Boot] 어떻게 DTO를 재구성할까?스터디 & 프로젝트/Init Cloud 팀 프로젝트 2023. 3. 20. 16:19
요즘 주변에서 들은 얘기나 하나 둘 본 자료, 강의에서 뭔가 떠오르는게 있었다. 바로 끔찍하게 구성된 DTO를 다시 만드는 것이었다. 공식적으로는 끝난 프로젝트임에도 맘에 안드는 부분을 바꾸고 싶었다. 중복을 제거하려고 무자비하게 상속관계로만 작성한 DTO 클래스는 너무나도 유지보수가 힘들다는 것이었다. 그래서 이 DTO를 재구성해보기로 했다. 문제 상황 대충 이런식으로 구성된 DTO 패키지가 있었다. 비즈니스로직마다 각각의 DTO를 가지고 있고 부모인 UserDto부터 내려오는 구조다. 이게 너무 난잡하다고 생각했다. 어떻게 개선할까? 우선 UserDto라는 부모 클래스는 유지하기로 했다. Dto를 보면 Profile, Retrieve 등등 회원 정보를 관리하기 위한 Dto가 있고 Signup, Aut..
-
[Spring Boot] 서비스 레이어 리팩터링하기스터디 & 프로젝트/Mineme 프로젝트 2023. 3. 15. 20:38
늘 일을 벌이는 나다. 욕심만 그득그득해서 그런가보다. 사이드 프로젝트하면서 내가 구현한 비즈니스 로직을 함께 협업하는 친구 개발자에게 전달해야 했다. 내가 맡은 파트에서 구현된 메서드를 래핑해서 사용하고자 하는데 거기에 요구한 클래스와 메서드 인터페이스는 유지해달라는 요청이 있었다. 그에 따라서 내가 어떠한 방식으로 메서드를 추가하고 어떻게 구조를 변경하는 편이 좋을지 고민했다. 요구사항과 현재 상태 확인 우선 내가 맡은 파트는 사용자, 인가 쪽 도메인이다. 친구가 맡은 파트는 만들고자하는 서비스가 제공하는 핵심 기능 중 하나인 글 쓰기 관련 도메인이다. 요구사항 사용자가 글을 작성할 때 사용자가 정상적인(권한, 가입여부) 사용자인지 파악하는 로직이 필요 사용자가 글을 작성할 때 사용자가 정상적인 상태..
-
[MariaDB] 인덱스로 성능 향상 체감하기스터디 & 프로젝트/Init Cloud 팀 프로젝트 2023. 3. 3. 22:40
이유 프로젝트로 백엔드 API를 만들고 있었다. 이미 기능은 모두 완성되었고 리팩토링이나 버그 수정 등등 만이 남았다. 예전부터 DB 성능 개선을 한번 해보고싶어서 해볼까 했다. 그래서 가장 많이 들어왔던 적절한 Index 적용을 통한 조회 성능 개선을 하고싶었다. 근데 문제는 DB 자체의 레코드가 많지 않다는 것이었다. 진행하는 프로젝트 특성 상 일반적인 웹 서비스처럼 Insert, Update 쿼리가 많이 발생하지는 않고 DB에 저장된 기본 데이터를 조회하는 로직이 많았다. 그래도 뭐 일단 진행해보기로 했다. 인덱스는 PK가 아닌 UNIQUE VARCHAR 필드에 지정했다. 최초 시도 정말 규모가 작은 DB이다보니 솔직히 성능 향상을 체감하기는 어려울 것이라 생각했다. 그도 그럴 것이 히스토리를 관리..