개발 기록

[Error] 일정 트러블 슈팅 2- 양방향/단방향

첫번째 트러블슈팅 [Error] 일정 관리 트러블 슈팅 1 - 제네릭제네릭이 개념중에 가장 코드 적용으로 바로 이어지기 힘든 부분이었다. 필수과제 구현까지 총 3번의 제네릭 활용 리팩토링을 해보았는데 그 과정에서 시행착오가 많았기 때문에 정리해보려고devz0.tistory.com문제리팩토링을 진행하며 User, Schedule, Comment 세 도메인 간 연관관계를 다시 보던 중, “단방향으로 유지할지, 양방향으로 전환할지” 판단이 애매했다. 특히, 단건 조회에서 일정과 댓글을 함께 보여주는 엔드포인트 설계를 하며 “일정 단건 조회시 댓글목록을 항상 참조하는데 Schedule ↔ Comment를 양방향으로 바꿔야 하나?”라는 고민이 있었다.⚠️ 이전입문과제는 일정과 댓글을 양방향 매핑으로 관계를 설정..

[Spring] DELETE 메소드에 RequestBody를 지양해야 하는 이유

글 삭제시 유저가 입력한 패스워드와 작성자의 패스워드 일치시 삭제를 구현해야했는데 강의대로 따라가다보니 @DeleteMapping과 @RequestBody를 같이사용하게 되었다.피드백HTTP Method중 GET과 DELETE에서 RequestBody의 사용은 지양해야 합니다. 지금은 HTTP Method를 정의한 문서에서 GET과 DELETE에서 RequestBody(요청 본문)의 의미가 정의되어있지 않기 때문입니다. 다시말해 요청본문이 있어도 그것이 어떤역할을 해야할지 명확하지 않아 무시되거나 거부될 수 있습니다. 실무적인 관점에서는 사용하는 라이브러리/프레임워크/버전에 따라서 DELETE에 요청본문을 허용하지 않는 것들이 있습니다.또한 일반적으로 DELETE에 요청본문을 넣지 않는다는 룰이 있어 다..

[Spring] Filter

Filter란?Filter는 Spring 전용 기술이 아닌, 자바 서블릿(Java Servlet) 표준 스펙에서 제공하는 기능이다.즉, Spring이 등장하기 전부터 톰캣(Tomcat), 제티(Jetty) 같은 서블릿 컨테이너 수준에서요청과 응답을 가장 먼저 가로채어 처리하는 구조다.Spring Boot는 이런 Servlet Filter를 내부적으로 자동 등록하고Spring 애플리케이션의 맨 앞단(DispatcherServlet 이전) 에서 실행되게 해준다.동작 구조클라이언트 요청 ↓[Filter] ─── Servlet 레벨 (보안, 인코딩, 인증) ↓DispatcherServlet ─── Spring MVC 진입점 ↓[Interceptor] ─── Spring 레벨 (로깅, 권한 검증,..

[Error] 일정 관리 트러블 슈팅 1 - 제네릭

제네릭이 개념중에 가장 코드 적용으로 바로 이어지기 힘든 부분이었다. 필수과제 구현까지 총 3번의 제네릭 활용 리팩토링을 해보았는데 그 과정에서 시행착오가 많았기 때문에 정리해보려고 한다.문제 1- 전역 validator validator를 앞으로 도메인 추가될 것을 생각해 전역으로 관리하고 싶었다. Schedule, User, Comment 다른 도메인에서도 거의 동일한 패턴의 검증 로직이 필요했는데 각각의 도메인명에 맞는 메소드를 계속 추가하자니 전역으로 관리하는 이유가 없었다.❌ 기존 코드public Schedule findScheduleOrException(Long scheduleId) { return scheduleRepository.findById(scheduleId) ..

문제새로운 스프링 프로젝트 테스트 실행시 다음과 같은 오류가 콘솔창에 뜸Port 8080 is already in useIdentify and stop the process that's listening on port 8080 or configure this application to listen on another port.8080 포트를 이미 다른 프로세스에서 사용 중이라는 뜻나는 분명 이전 프로젝트 서버를 껏는데?이전 프로젝스 서버 죽이고 새로운 프로젝트를 실행했다.개발 중 의도치않게 포트가 점유된 상태로 서버가 백그라운드로 남는 경우가 종종 있다고 한다.appication.properties 파일에서 포트를 예를들어 8081 로 바꿔줄수도 있지만 정석대로 원인을 해결하는 방법으로 정함.상황 진단터..

영속성 컨텍스트데이터베이스와 애플리케이션 사이에 JPA가 만든 임시 저장소(캐시)영속성 컨텍스트의 역할역할설명이해를 위한 비유① 1차 캐시같은 엔티티를 두 번 조회해도 DB에 다시 안 감한 번 불러온 책은 책상 위에 둔다② 변경 감지 (Dirty Checking)엔티티의 필드가 바뀌면 자동으로 UPDATE 감지책을 수정하면 포스트잇으로 표시해둔다③ 쓰기 지연 (Flush 시점에 DB 반영)INSERT, UPDATE, DELETE가 트랜잭션 끝날 때 실행됨숙제는 한 번에 제출한다DB 접근을 최소화한 ORM이 효율적인 ORM생명주기에 따른 4가지 상태상태설명예시비영속 (new)아직 JPA에 저장 안 됨new Todo("공부")영속 (managed)EntityManager에 저장되어 관리 중em.persist..

예전에 공부용으로 homebrew로 설치된 mysql이 있었는데 이번에 예제 따라간다고 웹에서 MySQL 8.4 dmg를 추가 설치하면서 두 버전이 같은 포트와 데이터 디렉토리를 공유하며 지속된 충돌문제가 발생했다.발생된 로그로그설명Unable to lock ./ibdata1 error: 35InnoDB 데이터 파일(ibdata1)을 중복 프로세스가 잠그려 함Can't connect to local MySQL server through socket '/tmp/mysql.sock'이미 다른 인스턴스가 포트를 점유하거나 소켓 경로 다름Access denied for user 'root'@'localhost'root 인증 플러그인 꼬임 (caching_sha2_password ↔ mysql_native_pas..

상황 요약단건 조회시 1:N 양방향 관계로 설정된 A 엔티티와 연결된 B 엔티티 목록을 함께 내려주는 기능을 구현해야 했다.@Entitypublic class Todo { @OneToMany(mappedBy = "todo", fetch = FetchType.LAZY) private List comments = new ArrayList();}@Entitypublic class Comment { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "todo_id") private Todo todo;} Todo를 불러와 그 안의 todo.getComments()를 호출했을 때 다음과 같이 쿼리 두번이상 실행되는 문제가 발생했다.select..

문제단건 조회시 해당 엔티티에 딸린 댓글들을 가져올 때 엔티티를 그대로 반환하면서 무한 루프 문제가 발생했다.Todo와 Comment는 서로 양방향 연관관계로 연결되어있다. 원인@RestController는 반환값을 자동으로 JSON 직렬화한다고 한다. 그때 양방향 연관관계에서 Jackson이 Todo 객체를 JSON으로 변환하려 함Todo 내부의 comments를 직렬화하려 함각 Comment는 다시 todo를 가지고 있어서 Todo 직렬화 시도Todo → Comment → Todo → Comment … 🔁와 같은 순환문제가 발생한다. 즉, 객체가 서로를 참조하고 있어서 JSON 변환이 무한 루프에 빠지는 것해결해결방법은 여러가지가 있다고 하는데 나는 @JsonManagedReference / @Js..

어려웠던 부분1.JPA 관계 설정ERD도 그려봤고 엔티티에도 다대일 일대다 양방향 관계 설정도 했다. 문제는 DTO. 사실 그냥 내 문제잘못된 설계Comment comment = new Comment( request.getContent(), request.getUsername(), request.getPassword(), request.getTodo() // ❌ request에서 Todo를 직접 받음);이건 request DTO에 Todo 엔티티가 직접 들어있다는 전제인데, 클라이언트는 Todo 엔티티 구조를 모름 Todo의 id만 알고있음DTO는 엔티티를 몰라야함!!또한 JPA가 관리하지 않는(영속되지 않은) Todo 객체가 들어가면 연관관계가 깨질 수 있음DTO는 단순히 데이..