#
로컬에서는 모든 테스트를 통과하는데 aws에서만 유난히 계속 실패했다...
얻은 교훈 : 역시 코딩할 때는 하나부터 열까지 다 의심하고 이게 맞을까?라고 생각할 시간에 검증해보는게 빠르다..
#
이유를 찾고자 하나씩 수정하면서 commit을 날렸다. 혼자 작업하는 거라서 커밋 어떻게 날리든 상관없었음..
Test클래스에 @Commit도 붙이고 괜히 @modifying도 붙여보았다. 근데 이들은 문제가 아니었다. 마지막 커밋에서 나와있듯이 Store->store로 바꿔서 해결할 수 있었다. 왜인지 알아보자.
#
먼저 위의 사진을 보면 StoreRepositoryTest의 findByLocation()에서 예외 발생이다. 오류 스크린샷을 보면 StoreRepositoryTest:112에서 발생한다고 나와있음.
함수는 아래와 같다.
#
테스트가 아닌 repository의 실제 findByLocation()함수는 아래와 같다. 위도 경도를 계산해서 가장 가까운녀석부터 페이징 처리한다. native sql로 처리했다. (참고로 mariadb를 사용했다.)
결론부터 말하자면 sql문의 store가 문제였다. 처음에는 Store라고 했었는데 이를 store로 고치니까 잘 동작했다...
(대문자->소문자)
어떻게 알게되었냐면 삽질하다가 발생한 예외인 invalidDataAccessResourceUsage~ 는 컬럼명이 잘못되었다거나 하는 문제일 확률이 높다는 것을 알게 되었다. 확인결과 컬럼명은 아무런 문제가 없었다. sql은 대소문자를 구분하지 않으니까 Store가 문제가 될줄은 몰랐다... 그래서 오늘의 교훈 항상 의심하자...
#
참고로 nativeSQL을 사용할 때는 @Param을 꼭 사용해야 매개변수를 바인딩해준다. 파라미터와 이름이 같으면 알아서 바인딩 해주는줄 알았는데 안해준다.
#
혹시나 싶어 테스트 실패상황을 재현해보았다. 아래처럼 대문자 store->Store로 고쳤다.
바로 재현 성공.
SQL은 대소문자 구분안하는데..왜...
결론 : @Query를 사용해서 native sql을 사용할 때는 대소문자 조심하자..
@
증거 : 로컬에서는 모든 테스트가 성공..
왜 이런 일이 발생하는 걸까... 이건 내가 생각해도 어떻게 찾았나 싶다.. 나 대단한듯..
