DevBoi

onetoone 관계의 두 객체가있었다. 둘은 조인을 하고있었고 연결된 다른 객체를 삭제하려고 delete 쿼리를 날렸지만 되지않았다. 당연히 안된다. 이건 JPA를 떠나서 DB 제약조건 때문에 안되는것이다. 바로, 연결된 다른 객체에서 값을 잃어버리기 때문이다. 그래서 찾아본 결과 JPA orphanRemoveal을 제공해준다. 이게 무엇이냐? @OneToOne(cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.EAGER) @JoinColumn(name="post_comment_id") private PostComment postComment; 이런식으로 고아 객체 트루로 주게되면 post에서 하위값을 null로 set하고 저장하면 ..

JPA에서 QueryDSL 하기 귀찮아서 그냥 JPQL로 사용하던 중 문제가 발생 delete 쿼리에서 자꾸 DML을 지원안한다는둥 이상한 버그가 많이 떠서 안된다.... 해결 방법 (Modifying) @Modifying @Query("delete from PostComment m where m.post.postId = :postId") void deletePostComment(Long postId); 추가로 서비스 단에 트랜잭션 묶어주기 수정, 삭제는 트랜잭션을 메소드 별로 묶어주는게 좋다. 이유는.. 트랜잭션의 기본을 안다면.. 다알듯... 무튼 JPA는 자동 트랜잭션 처리를 지원해주지만. 혹시나 몰라서 명시를 하긴했다. 사실 해결은 Modifying이 크다. 앞으로는 그냥 QueryDsl로 설계해..

1. TimeEntity를 하나 생성한다. @MappedSuperClass JPA Entity 클래스들이 해당 어노테이션이 붙은 클래스를 상속한 경우 해당 클래스의 필드를 컬럼으로 인식하게 한다. @EntityListeners(AuditingEntityListener.class) 해당 어노테이션이 붙은 클래스에 Auditing 기능을 포함시킨다. @CreatedDate Entity가 생성되어 저장될 때 시간이 자동 저장된다. @LastModifiedDate 조회한 Entity의 값을 변경할 때 시간이 자동 저장된다. 2. 사용하여 추적을 사용할 엔티티를 상속 받게 한다. 3. 메인 클래스에서 추적기능을 킨다. 이러면 끄읏, 정상적으로 되나 보자 된다!

Spring bean scope Spring bean scope 가 뭔말이지? 싱글 턴 다 똑같은거 아닌가? 스프링에서는 빈을 싱글턴이나 여러개의 방식으로 사용할 수 있도록 설정을 제공해준다. 한번 해보면서 확인해보자 SingleTon Prototype WebScope3-2. session3-4. websocket 3-3. application 3-1. request 이런 계층 형으로 분류가 되어있다. 사실 웹 스코프 위주로 볼 것이다. 싱글 톤이랑 프로토 타입은 많이 써봐서…ㅎ SingleTon 싱글톤 스코프 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 빈을 반환한다. 2.프로토타입 스코프 프로토 타입 스코프의 빈을 조회하면, 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다. 프로토..

일단 기본적인 구조는 아래와 같다 Controller > Service > Repository 이외 해당 API에 대한 설명은 스웨거로 작성을 하였고 게시물, 회원에 대한 간단한 Controller,Service, Repository는 아래와 같다. 소스 코딩은 별로 하지 않았고, 시간도 적었다. 러닝 커브는 심하지만, 이러한 JPA의 장점과 좋은 점들을 최대한 활용해보고자 하였고 추후에 QueryDsl 까지 섞어서 개발을 진행할 예정이다. 또한 트랜잭션 관련 개발 내용도 구조와 개념을 상세히 스터디해서 포스팅 할 예정이다. 공부의 의미가 적은 비즈니스로직은 사실 일일히 포스팅 할 필요가없어서 구조에 대한 개념을 잡기위해 아래와 같이 대충 포스팅 ㅋ

DTO와 Entity 간의 설정은 JPA에서 필수 조건이라고 생각한다. Entity를 DTO처럼 사용한다면, 나도 모르는새에 트랜잭션이 닫히면서 디비로 쿼리가 나갈수도있고 데이터가 바뀔수도 있기 때문이다. 이전에는 ModelMapper라는 기능을 사용했지만 이건 생각 보다 단점이 많은 기술이다. 쓰면서도 대충 느낌이 오긴했지만, 자세히 안좋은 점들과 어떨때 쓰면 좋을지는 추후 포스팅에서 다루기로 하고 일단 바꾼 방식에 대해서 정리해보자 일단은 빌더 패턴이다. 엔티티에서는 dto를 파라미터로 받아서, 세팅해주는 빌더를 선언해준다. 실제로 다 빌더로 넣어줄수도있지만, postId같이 자동으로 seq같이 붙는 값을 관리해주기위해 해당 유형의 값은 빼고 관리해주자 DTO에서는 이렇게, getEntity라는 메소..

도메인은 우선 기본적으로 크게 4가지로 잡았다. User - 사용자 Post - 게시물 master PostContent -게시물 요청자 PostComment - 게시물 작업자 Asset - 자산 자산은 이력성으로 쌓고, 게시물도 이력성으로 쌓을 것이다. 그이유는 스케줄러나 배치로 주기적으로 회원들 정보를 갱신해주는것도 좋지만 그렇게 많은 사람들의 작업이 있지않는 이상,이를 굳이... 뭐 나중에 데이터가 점점 쌓이면 등급에 대한건 그떄 고민해보자 스케줄러던 배치던 무튼 이렇게 4개에 대한 도메인을 설계했고, 해당 관련 개발까지 머리속으로 설계는 끝냈다. 사실 개발하는것 자체보다 설계에 시간을 많이 쓰긴했다. 이 모델 기반으로 JPA를 설계할 것이고 개발해 나갈 것이다. mybatis를 쓸까 고민도 하긴했..

MSA에서 필수, Config 서버 분리 및 중앙 집중 관리 공부해보자 Spring 설정 파일을 외부로 분리할 수 있는 Spring cloud Config 이다. Spring Cloud Config 는 분산 시스템에서 설정파일을 외부로 분리하는 것을 지원한다. Spring Cloud Config를 사용하면 외부 속성을 중앙에서 관리할 수 있다. 즉, 각각 공통으로 쓰는 설정값들을 각 서버마다 배포할 필요가 없다는 뜻이다. 다양한 애플리케이션에서 동일하게 설정파일을 사용할 수 있다. 즉 한 서버에서 설정값들을 모아서 관리하고 다른서버에서 config에 대한 값을 참조시에 해당 서버에게 물어보고 동일하게 가져오는것이다. 이건 개념은 별로 없고... 그냥 한번 사용하면서 예를 들어보자 우선 Config Ser..

써킷 브레이커....실무에서 몇번 쓰이고 사실 비즈니스 로직만 짜는 단순 개발자가 아니라... 미들웨어를 배치 받거나... 클라우드를 쓰면 항상 나오는 개념이다. 써킷 브레이커 대충 느낌만 알아서 정리를 해보자 Hystrix를 이용해서 써킷브레이커를 구현하는 경우가 많다. 우선 Circuit breaker란? MSA에서 자주쓰이는 개념이다. 장애전파를 막아주는 역할을 한다. 예를 들어서 어떤 페이지를 호출했다고 가정해보자 그 페이지에서 여러 API를 호출하게 되는데, 해당 특정 한 API에서만 오류가 있다고 가정을 했을때, 해당 한개의 API 때문에 페이지가 504나, 에러페이지로 가는 경우가 있다. 이러한 경우를 막아주는, 즉 MSA환경에서 더 MSA같이 장애전파를 막아주는 개념이 써킷 브레이커다. 물..

최근 사이드 프로젝트를 계속 진행하면서, 뭔가를 정리할 시간이 없었다... 뭔가 알고는 있었지만 계속 찾아서 써먹는 ModelMapper에 대해서 정리를 해보려고한다. 잘알다 싶이, JPA에서 사용하는 Entity는 DTO로 사용하면 절대 안된다. 쉽게 얘기하면, DB layer와 view layer에서 각각 엔티티와 DTO를 다르게 사용해야한다. 이유는 다양하지만, JPA특성상 엔티티의 값을 set하고, save하면 자동으로 디비 쿼리가 나가기 때문에가 가장 크다고 생각한다. Entity를 Dto처럼 쓴다면, 추후 운영 상에 디비에 대한 정보를 의도치 않게 바꿀수 있다. 그래서 Entity와 Dto를 분리해야하는데, Entity로 정보를 얻고, 이걸 Dto로 변환하려면 어떻게 해야할까? ModelMap..