DevBoi

java.sql.SQLNonTransientConnectionException: (conn=48) Got a packet bigger than 'max_allowed_packet' bytes 오류가 발생할 수 있다. 아래 두개의 커맨드를 입력해서 디비 설정 값을 바꿔주면 된다. set global max_allowed_packet=1000000000; set global net_buffer_length=1000000;

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하고 저장하면 ..

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

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

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

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

우선 구조를 살짝 바꿨다. 인터셉터는 그대로두고 한 메서드에서 로그인 하면 Admin type 에 따라서, 다른 view를 띄워주는 방식으로 모델부분이다. SuperAdmin과 NormalAdmin의 두 부분을 나눠서 make하였다. 생성자를 별도로 만들지 않은 이유, 빌더를 만들지 않은 이유는 JPA에서는 메서드명을 생각없이 지으면 나중에 운영관리하기 빡세기 때문,... 무튼 이제 두가지 화면을 구성해야한다. 1. NormalAdmin으로 사용자 정보를받아서, 디비에 넣는것 2. SuperAdmin으로 들어가면, 사용자 정보에 맞춰서 버튼 누르면 다음 사람에게 알림톡 나가는 것 1번부터 해보자 우선 등록을 완료하면, 등록이 완료한다. User에서 statCd 별로 유저를 관리하고 입장전 10. 입장 후..

우선 Primitive type은 null을 허용하지 않고, wrapper class는 null을 허용한다. 만약 Long으로 하지않고, long으로 한다고 가정하면 값이 0인 경우 없는건지, 아니면 id 자체가 0인지를 알수 없다. Wrapper타입인 Long이나 Integer를 쓰면, id가 없는 경우, 확실히 null로 id가 없다는 것을 보장할 수 있다. 추가로, 이 id가 없다는 것으로 신규 객체인지 기존 객체인지 확인도 가능하다

패치조인은 JPQL에서 성능 최적화를 위해서 제공하는 기술이다. 연관된 엔티티나 객체를 한번에 조회해 오는 기능이다. N+1 문제가 발생하는 경우, 발생가능성이 있는 경우, 연관관계를 맺고 있는 다른 엔티티까지 한꺼번에 조인을 사용해서 실제 엔티티의 값을 가져온다. 단 한번의 쿼리로 값을 다 가져오기 떄문에, N+1 문제 발생 가능성을 차단할 수 있다. 일반 조인 : 조인을 대상으로 한 테이블의 값을 가지고 조회하는 대상의 테이블의 값을 가져올때 사용하는 것이 다이다. 즉, 대상 엔티티의 값을 가져오는 기준으로만 사용하고, 별도 조인 대상의 엔티티의 값을 가져오지는 않는다 패치 조인 : 조인 대상 엔티티의 값을 함께 가져온다. sql에서의 distinct는, 중복을 제거한다. 즉 특정 컬럼에 대한 중복을..

N+1 문제는, JPA의 Entity 조회시, Query 내부에 존재하는 다른 연관관계에 접근할 때 또 다시 한번 쿼리가 발생하는 비효율적인 상황을 일컫는 말입니다. 1. 즉시 로딩 변경후, findAll로 조회하는 경우 OneToMany의 기본 로딩전략은 LAZY이지만, 해당 전략을 즉시로딩으로 변경하고 findAll을 하게되면, 하위 연관관계에 대한 전부를 조회해야하기 때문에 N+1이 발생할 수 있다. ex. Post와 comment인 경우 Post를 조회하고, 하위의 comment를 전부 조회한다. 즉, Post의 개수대로, comment를 조회하는 쿼리가 추가로 나간다. * 해결 방법 지연로딩으로 변경 2.지연 로딩 변경 + Loop 조회 findAll로 가져올때는 N+1 발생하지 않는다(지연 로..