문제 요약 이번에 카드 엔티티의 질문(Question) 속성과 설명(Description) 속성의 허용 길이를 늘려달라고 부탁받았다. Description의 경우 원래 CLOB이기에 큰 문제 없었지만 질문속성의 경우 VARCHAR2(2000)으로 정의되어있었다. 이를 5만자로 허용하기 위해서는 CLOB으로 변환해야 했다. 그래서 application code를 수정하고 validate -> update로 hibernate:ddl-auto를 수정했는데 application 시작에는 큰 문제가 없었지만 조회시 다음과 같은 에러가 발생했다. 쿼리를 실행할수 없고 invalid column type이라 쿼리할 수 없다는 것이였다. 그래서 실제 db장소인 oracle cloud를 확인해보니 CL

기존 문제점 실제 만든 서비스를 이용하려고 하니 도커로 인스턴스 서버에 생성한 DB가 불안했다. 그 이유는 MySQL 이미지를 컨테이너로 띄우면 메모리를 700M 정도 잡아먹는데 여기에 nginx, application server까지 띄우니 1GB 사용을 뛰어 넘는다. 결국 메모리 스왑을 사용해야 하고, 서버가 느려지게 된다. 그 뿐만 아니라, DB의 데이터를 조금 더 안전하게 보관할 방법을 찾아야 하는데 이 때문에 DB를 클라우드 서비스를 활용해서 분리해보기로 했다. 보통 AWS RDS를 많이 사용하는데,

@Transactional 공부 계기 Transactional은 보통 서비스 레이어에서 메서드에 관용적으로 사용한다. 조회만하는 경우 readOnly=true로 설정하기도 하고 경우에 따라 세부적인 내용을 적용한다. 이번에 Transactional을 분석하려는 이유는 jpa의 entityManager의 생명주기와 더불어 @Transactional과 어떤 관계가 있는지 확인해보기 위해서다. 프로젝트에서 이 문제때문에 얘기지 못한 문제가 발생했었기 때문이다. @Transactional 어노테이션과 AOP 어노테이션을 메서드에 달아서 사용한다 -> 대부분 AOP @Transactional 어노테이션은 메서드에 달아서 메서드 로직 수정 없이 transaction을 활용할 수 있도록 한다. 이는 AOP라 할 수 있다. 그렇다면 Spring에서 @Transactional 어노테이션과 AOP를 어떤 방식으로 활용하고 있을까? AOP를 활용하려면 Advisor가 있어야 한다

발생한 문제 회원 정보 수정을 요청하는 API를 만들었는데 DB에 수정사항이 반영되지 않는 이슈가 있었다. 문제의 코드는 다음과 같다. null을 체크하고 null 아니면 해당 속성을 업데이트한다. 이때 save 요청을 하지 않은 이유는 인자로 가져온 엔티티가 영속화 상태일 것이라 생각하고 자동으로 더티 체킹을 수행하리라 생각했기 때문이다. 위와 같이 Member 엔티티를 인자로 받은 이유는 @AuthenticationPrincipal을 활용해 SecurityContext에 있는 회원 정보를 뺴올 수 있었기 때문이다. SecurityContext에 Member 엔티티가 있는 이유는 jwt token 검증 filter 에서 인증에 성공하면 db에서 엔티티를 가져온다. 즉, 회원 수정 요청은 2개의 트랜잭션으로 동작한다. ![](https://velog.velcdn.com/images/e1psycongr00/post/00ab7814-bbe1-4328-b3f

매개변수의 null 체크 필요성 API 개발중 카테고리 ID를 입력하면 이를 바탕으로 해당 카테고리 내부의 카드를 페이징 조회하는 쿼리를 만들어야 했다. 이 때문에 categoryId 인자가 반드시 필요하다. 보통 NPE 문제를 막고 인자에 유연하게 동적으로 쿼리를 생성하기 위해 Querydsl에서 다음과 같은 BooleanExpression을 작성한다. 해당 코드의 장점은 유연하고 동적으로 처리 가능한 쿼리를 작성하는데 도움을 준다는 것이다. 그러나 내 케이스의 경우엔 반드시 CategoryId의 입력을 강제해야 한다. 즉 인자의 입력이 절대로 null여서는 안된다는 것이다. 그래서 Null을 체크해야 하는 로직을 최상단에 구현해야 했다. (npe 결과를 기다리는 것이 아니라 미리 체크해서 디버깅을 용이하게 하고 실패지점을 명확히 한다) Null 체크 방법 선택하기 null을 체크하는 방법에는 크게 3가지가 있다. 직접 최상단에 체크하기 Gua

더티 체킹 https://jojoldu.tistory.com/415 더티 체킹에 대해 간략하게 잘 설명되어 있는 블로그다. > 더티 체킹이란 트랜잭션 내에서 영속화 상태의 엔티티의 데이터가 변경되면 별다른 요청 없이 트랜잭션 종료시 변경값으로 update 된다. 더티 체킹은 JPA의 핵심 기술이라 볼 수 있다. 기본적으로 영속화를 하면 엔티티는 영속 컨텍스트에 저장되며 entityManager가 이를 관리한다. managed(영속)상태의 데이터는 커밋시에 반영되며 수정 변경된다고 해서 바로 쿼리를 호출하지 않는다. 이렇게 쿼리 생성 및 동작을 지연시키는 방법을 통해 성능을 올릴 수 있다.(db에 데이터를 넣고 조회할 때 커넥션과 projection 작업은 보통 application보다 무거운 작업이다) 더티 체킹은 detach나 비영속 상태에서는 동작하지 않는다. 더티 체킹 테스트에서 발생한 문제 카테고리 엔티티를 수정하는 코드이다. 그리고 이 코드를 테스트