Binder프로젝트

DTO에서 Entity로 변환할 때 두가지 방법을 쓸 수 있다.첫번째는 DTO에서 DTO의 엔티티 변환을, 두번째는 엔티티에서 책임진다.나는 이걸 DTO와 엔티티의 결합 관점에서 바라보면 좋을 거 같다.2번의 경우, 만약에 DTO를 변경한다면 엔티티 내부가 변경돼야 한

예외는 개발자들이 처리할 수 있는 예외가 있고그렇지 않은 예외가 있다.지금 고민하는 DTO에서 잘못된 값이 왔을 때는 흔히 말하는 '개발자가 처리할 수 있는 예외'다.null값을 허용하지 않는 곳에 null이 들어왔다면?NullPointerException이 터지도록

dev 브랜치에다가 실수로 커밋을 했다.pick을 drop으로 바꿔준다.

Seoul_Nolgoat 프로젝트와 binder 프로젝트를 하면서 좌표를 DB에 넣을 일들이 생겼다.이렇게 위치 기반 서비를 하다보면 특정 반경에 있는 가게들을 조회해야 할 때가 있다. 좌표에도 인덱스를 적용할 수 있어서 Point를 활용하기로 했다. 참고 : 공간 데

JPA를 사용해서 쿼리를 직접 짤 때는 JPQL과 네이티브 쿼리를 쓸 수 있다. 네이티브 쿼리는 일반적으로 사용하는 SQL 쿼리를 쓸수 있도록 해주는 기능이다. JPQL은 테이블이 아닌 객체를 대상으로 쿼리를 작성한다. DB에 독립적인 쿼이다. 이러한 쿼리들을 사용하

이번에 쓰레기통 정보를 DB에 넣으면서 좌표를 넣어야 할 일이 생겼다. 지난번에 가게의 위도 경도를 DB에 넣을 때 좌표가 소수점 특정 자리에서 반올림되는 문제가 있었다. 혹시나 싶어서 DB에 데이터를 넣고서 확인해봤더니 역시 반올림됐다. 원래 좌표는 이런식으

이 쿼리는 인덱스를 탈까?확인해보니 인덱스를 타지 않았다.풀스캔 방식이다보니 아무래도 0.4초 정도의 딜레이는 생긴다.ST_DISTANCE를 사용한 쿼리는 포함관계를 확인하는 것이 아니라, 모든 데이터와 기준점과의 거리를 계산하여 반환하는 쿼리라서 그렇다.쿼리는 이렇게

이번 Binder 프로젝트를 하면서 같이 백엔드를 하는 팀원과 테스트 코드를 열심히 짜자는 이야기를 했다.사실 나도 테스트코드를 짜지 않고 구현만 하는 경우가 꽤 많았아서 이번에 좀 열심히 해야겠다는 생각이 들었다.그래서, 일단 push-pull 하고 무조건 전체 테스

DTO enum 필드 사용현재 검색을 할 때 쓰레기통의 타입을 Enum으로 제한해서 값을 가져오고 있다.우선, 고민하게 된 이유는 DTO에서 비즈니스 로직을 검증하는 것을 줄이는 게 좋다고 생각했기 때문이다.DTO에서 값 검증을 할 수는 있지만 이건 정말 데이터 형식과

처음에 스프링 설정파일에 ?rewriteBatchedStatements=true와 spring.jpa.properties.hibernate.default_batch_fetch_size=100이 두가지를 넣지 않았는데도 DB에 데이터가 JDBC Template의 batc

즐겨찾기 하나를 생성하는 데 발생하는 쿼리의 수다.우선, 쿼리가 많다는 것 자체가 개선이 필요한 부분이라고 생각했다.현재 구조에서는 member와 bin을 각각 따로 조회하고, bin을 조회하면서 bin_registration까지 같이 조회해야 한다.이걸 하나의 쿼리로

이렇게 보내는 별거 아닌 코드에서 계속 입력값 에러가 떠서 뭐지?? 하면서 원인을 발견할 수가 없었다. DTO에 값매핑이 뭔가 잘 안되는 거 같았다. 이렇게 컨트롤러단에 브레이크 포인트를 걸어도 여기서 멈추지 않고 바로 잘못된 입력값이라는 메시지와 400코드가 떴기 때

이번 프로젝트에서는 이용자들이 쓰레기통에 좋아요, 싫어요, 북마크를 할 수 있도록 했다. 문제는 각각 중복해서 좋아요를 하거나 싫어요를 할 수 있는 상황이 있다는 것이다. 그래서, DB에서 먼저 이 이용자가 해당 쓰레기통을 좋아요/싫어요/북마크 했는지 확인하고 그렇지

같이 팀작업을 하는 백엔드 팀원이 100명의 사람이 특정 작업을 하면 동시성 이슈가 생기는 부분을 테스트했다. 그 과정에서 새로 배우는 내용이 많으셨다고 해서 나도 이번에 다시 동시성 이슈 테스트를 해보기로 했다. 테스트 시나리오는 쓰레기통 하나에 100명의 사람이

일단 멀티 스레드 처리를 차지하고서라도 위 코드에서 bookmark 숫자는 최소 1이상은 돼야 한다. 하지만, 위 사진처럼 계속 북마크가 0이라고 떴다. 이전 글에서 멀티 스레드 환경에선 스레드마다 새로운 트랜잭션이 생겨서 영속성 컨텍스트도 달라진다고 말했다.

현재 북마크 목록을 가져올 때 위 처럼 페이지네이션 방식을 쓰고 있다. 노오프셋 방식이라서, 마지막으로 받은 bookmakrId 이후의 10개 목록만 전달해주는 방식이다. 이 방식을 쓰면 오프셋처럼 id 5000~5010까지 읽기 위해서 앞에 있는 데이터 5천개를

이 코드를 봐보자. 당연히 테스트가 통과할 거 같다. 하지만, 그렇지 않다. 테스트는 실패한다. 북마크 카운트가 100L이 아닌 10L이라서 그렇다. 동시성 이슈 해결하기 멀티 스레드 환경에서는 동시성 이슈가 발생할 수 있다. 동시성 이슈란 쉽게 생각하면, 데이

테스트를 돌리면서 이 부분이 깨지는 걸 확인해보니 DB에 저 욕설 데이터가 들어가서, 다른 테스트에서 동일한 욕설을 체크하고 DB에 넣는 로직을 수행할 때 중복예외가 떴다. 테스트에 @Transcational이 붙어있는데도 내용이 롤백되지 않고 커밋이 된 것으로