JIE0025

✅ Category Entity에 사용되었던 어노테이션 리팩토링 이전에는 어노테이션이 무분별하게 사용되고 있었다. @Setter @AllArgsConstructor @NoArgsConstructor(access = AccessLevel.PROTECTED) @Builder 잘 알지 못하고 마구 사용한 것을 반성하며 이것을 개선하기 위해 먼저 Setter와 AllArgs를 삭제했다. Entity 클래스이고, @id 컬럼의 GenerateType이 IDENTITY이기 때문에, AllArgs은 필요없다고 판단했고 Setter 역시 클래스 레벨에 사용하는게 좋지 못하다는 것을 들었고, 자유로운 객체 생성시엔 @Builder를 남기는게 맞다고 판단했다. 그렇게 @NoArgsConstructor(access = Ac..

object references an unsaved transient instance - save the transient instance before flushing 연관되어 있는 두엔티티가 존재하는데, save()하는 과정에서 오류가 발생한다. 오류메세지를 해석해보면 '개체가 저장되지 않은 임시 인스턴스를 참조합니다. - 플러시(영속화)하기 전에 임시 인스턴스를 저장합니다.' 즉 어떤 객체가 영속화 될 때, 연관된 객체도 영속화 해주는 코드가 필요하다 ✅ 영속성 전이를 사용한 해결 연관관계를 맺어주고, 영속성 전이를 사용해야 객체에 사용되는 행동이 그 관계를 맺어준 객체한테까지 전파되게 해야한다. 특정 엔티티에 대해 특정한 작업을 수행하면 관련된 엔티티에도 동일한 작업을 수행한다 JPA에서는 연관된 ..

✅ 이전 버전은.. 앞서 entitymanager를 직접 불러와 사용하는것 레포지토리르 2개나 만들어 사용한것 (서비스에 2개의 의존 레포지토리가 생겼다) https://jie0025.tistory.com/345 [Springboot][개발] FLAG - Category CRUD 1차 완성 (Merged) JIE0025 [Springboot][개발] FLAG - Category CRUD 1차 완성 (Merged) 본문 jie0025.tistory.com 예전에 스터디하면서 정리해놓은 글이 있어 해당 사용방법을 참고했다. https://jie0025.tistory.com/254 [Spring] QueryDSL 개인적으로 공부하면서 정리한 내용입니다 : ) FLAG Project - BE Study 2022..

//private final EntityManager em; //엔티티 매니저를 가져오는게 문제가 됨 >> 비추천 //JPA or JPQL or QueryBuilder (QueryDsl)을 이용해 개선이 필요함 public List findAll(){ return em.createQuery( "select c " + "from Category c " + "where c.parent is NULL" ,Category.class) .getResultList(); } 앞서 entitymanager를 직접 불러와 사용하는것 엔티티는 1개, 레포지토리를 두개씩 만들어 사용한것 (서비스에 2개의 의존 레포지토리가 생겼다) 두가지 문제가 있어서 QueryDSL을 사용해보는겸 개선을 해보고자 했다. 예전에 스터디하면서..

✅ 개요 프로그램을 만들어 잘 동작하는지 확인하려고 System.out.println()도 많이 썼다. 또 디버깅을 통해 데이터의 흐름도 볼수있었다. 이런것들은 다 로그의 하나로 볼수있다. 그럼 로깅은 뭘까? 로깅은 운영중인 웹 어플리케이션의 문제 발생시- 원인을 파악하기 위한 정보를 의미한다. 배포환경에서도 잘 되는지 확인하기 위해 결국 로깅을 알아야한다. ✅ 로깅이란? 프로그램동작시 발생하는 모든 일을 기록하는 행위 ⏺ 모든 일 :: 개발자가 가져야하는 최소한의 목적 ✔️ 서비스의 동작상태 확인 시스템로딩 http통신 트랜잭션 db 요청 의도를 가진 Exception ✔️ 장애 i/o exception nullpointerexception... ⏺ 로그의 장점 출력형식 지정가능 로그레벨에 따라 남기고..

테스트 코드는 아직 어려워서, 요청메세지를 통한 테스트만 확실하게 진행한 상태로 컴밋을 진행하기 위해 코드를 기록한다. ✅ 테스트 완료 글 https://jie0025.tistory.com/338 [현재 상황 분석] 어디가 문제일지 & 앞으로 봐야할 부분들 찾기 JIE0025 [현재 상황 분석] 어디가 문제일지 & 앞으로 봐야할 부분들 찾기 본문 프로젝트 - FLAG/테스팅 [현재 상황 분석] 어디가 문제일지 & 앞으로 봐야할 부분들 찾기 Kangjieun11 2022. 12. 19. 23:36 jie0025.tistory.com https://jie0025.tistory.com/343 [Postman][5] PUT- 카테고리 수정(컨트롤러 요청메세지 테스트)(PATCH 안쓸거다 ㅜㅜ) JIE0025 [..

카테고리 수정하는 부분에서 PATCH를 사용하면서 문제가 있었는데, 좀 알아보니까 PATCH용 DTO를 따로 만들고 그러는것 같다.. 카테고리에서 굳이 그럴 필요까지는 없을 것 같아서 PUT으로 바꾸고 테스트를 진행해야겠다. 나중에 PATCH를 쓰는건 연습을 따로 해봐야지.. ✅ GIVEN 일단 data 입력해주고, id가 5인 카테고리의 이름 "카테고리4"를 "ALGORITHM"으로 바꾸기! PUT으로 바꿨기 떄문에 전체 데이터를 보내준다. PUT http://localhost:8080/v1/categories/5 { "name":"ALGORITHM", "categoryDepth":2, "parentId":3 } PATCH는 참고할만한 예제가 많이 없어서 연습이 필요할 듯 하다 ㅠㅠ ✅ 결과 확인 잘 ..

오늘 열심히 테스트코드를 짜다가 핵심 로직이 문제인지, 테스트코드 문제인지 모르는상태로 열심히만한걸 깨달았다. 역시 사람은 생각을 하고 해야해... 따라서 현재 할 수 있는 최선은 1) POSTMAN으로 전부 다 보내보고 기능적으로 문제가 없다면 테스트코드 싹 갈아엎기? 만약 문제가 있다면 로직 바꾸기 (내일..) 2) 이전 글에서 바꾼 파일구조 저렇게 하면 안될것 같으니 피드백 받고 수정하기 (내일) 오늘의 내가 고통받으면서 구현은 했으니 내일의 나는 좀더 편하길...😂 (성공) POST 카테고리 추가 (실패) PATCH 카테고리 수정 왜..안돼..?일단 알았어.... 포스트맨이 이럴땐 고맙다 ㅠㅡㅠ (성공) GET : depth가 0인 카테고리 반환(모든 카테고리 데이터 JSON처리) (성공) DEL..

전체 카테고리 가져오는 테스트코드 작성하다가 동작을 안하길래 테스트코드 잘못적은건지 엄청 헤매다가.. 애초에 getCategories가 작동하지 않는 상황에서 테스트코드를 적으려고하니 아무것도 안되지라는 생각이 갑자기 들었따. . 나는 기록하면서 가야 빨리 버그를 찾는 듯 해서 빨리 찾고싶은 마음으로 기록하러 왔다. ✅ Given 일단 테스트를 위해 게시글을 만들어줬다. (일단 잘 작동하는 POST 요청메세지 ㅎㅎ..💙) get 메소드로 전체 데이터를 가져오는거에서 500 에러가 나는데 대체 이유를 알수가 없다. 어제까진 나그래도 성장속도 빠르다고 생각했는데 역시 난 아무것도 모르는 바보다 ㅠㅡㅠㅡㅠ 일단 어디서 문제가 나는지 확인을 하려고, 컨트롤러, DTO, Entity, Service의 작동하는 곳..

어제 만들어놓은 이 JSON데이터를 보고, 카테고리를 추가하는데 이대로 들어올일은 없다고 생각이 들었다. (자식이 있는 상태로 카테고리 추가하는건 말이 안됨) 이런 이유로 하나씩 추가하면서 테스트 해줄거다 + depth가 최대 3으로 해줄 것이기 떄문에 DTO 유효성 검사에 MIN(0) MAX(3)으로 줘야겠따. { "id:1, "name":"Activity", "categoryDepth":0 "children":[ { "id": 2, "name": "Study", "categoryDepth": 1, "children": [ { "id": 3, "name": "알고리즘", "categoryDepth": 2, "children": [ { "id": 4, "name": "개념반", "categoryDepth..