@JoinColumn(nullable = false, name = "notify_id") @OneToOne(fetch = FetchType.LAZY, optional = false) lateinit var notify: NotifyEntity​ JPA의 앤티티 셋팅을 하다가 특이한 점을 발견하였다. 1대1의 관계를 갖고 있고, FK를 필수로 갖게 하기 위해, @JoinColumn의 nullable 옵션을 false로 설정하였다. 그런데 @OneToOne의 옵션 중 optional 이란 특성을 알게 되었다. 일단 각각의 설명은 다음과 같다. @JoinColumn의 "nullable = false"에 대한 설명이다. @JoinColumn의 "nullable = false" (Optional) Whether ..

1. 컨트롤러(Controller) - 클라이언트에서 요청한 데이터 검증 - 클라이언트 응답 DTO(Data Transfer Object) 생성 2. 서비스(Service) - 비즈니스 유효성 검증 - 비즈니스 로직 3. 리포지토리(Repository) - DB 조회 컨트롤러, 서비스, 리포지토리의 역할에 대해 논의하였다. 컨트롤러의 역할이 많이 달라졌다. 이전에는 들어온 요청을 서비스로 전달하는 역할만을 가졌다면, 이제는 클라이언트가 요청한 데이터의 유효성을 검증하고, 서비스가 DTO를 만들어 리턴하는 것이 아니라, 앤티티로 리턴하고, 컨트롤러에서 DTO를 만든다. 이렇게 한 이유는, 컨트롤러와 서비스의 역할을 명확히 구분하기 위함이었다. 서비스는 비즈니스 로직만을 담당하게 하고, 컨트롤러는 서비스가 ..

queryDsl에서 조회 쿼리와 count() 쿼리의 공통 부분을 같이 쓰려고 작업하던 중 발견하게 되었다. PostgreSql은 count() 쿼리에서 order by 구문이 있으면 group by가 필요하다는 오류가 발생한다. count() 쿼리에서 order by 구문이 필요하지 않지만, MariaDB에서는 order by 구문이 있어도 쿼리가 실힝되었던 터라 이상함을 느꼈다. -- PostgreSql -> SQL Error [42803] select count(*) from test order by id desc ; -- MariaDB -> 실행 select count(*) from test order by id desc ; 검색하고 여러 방법을 시도해본 결과, MariaDB에서는 테이블 내의 컬..

4.0 프로젝트는 기관 정보와 기관 프로필의 앤티티를 나누었다. 현재 정책으로 기관은 하나의 프로필을 갖는다. 그러나 프로젝트 설계는 향후 멀티 프로필의 가능성을 고려해서 1:N 관계이다. 기관 프로필을 조회할때, fetchOne()과 fetchFirst() 중 무엇을 쓸 지 논의했다. fetchOne()은 한건 이상의 데이터가 조회되면 에러가 발생한다. fetchFirst()는 한건 이상의 데이터가 조회되더라도, 첫 번째 데이터만 조회하기 때문에 에러가 발생하지 않는다. 일견 생각하면 에러를 최소화할 수 있는 fetchFirst()를 쓰면 되지만, 그렇다면 fetchOne()는 왜 존재하는지 생각해보게 되었다. 결론은, 설계상 가능한 영역은 fetchFirst()로 처리하고, 불가능한 경우는, 예를 들..