728x90
문제사항 제시
나는 테스트 환경에서 h2 in-memory db를 사용하고 있었다. 통합 테스트를 하려고 했는데 에러가 몇시간 동안 발목을 잡았다.
ddl-auto: validate를 해놓은 상태이고 엔티티와 디비가 맞는지만 확인했다.
그런데 Flyway가 실제 디비에 어떻게 적용시켰는지를 알아야 엔티티를 디비에 맞추든, 디비를 엔티티에 맞추든 할 수 있었다.
(사실 엔티티를 디비에 맞추면 OCP 위반이기 때문에 엔티티를 디비에 맞추어야했다.)
그렇게 하려면 디비의 상황을 알아야 했는데 아무리 h2.console.enabled=true 로 해놓아도 http://localhost:8080/h2 가 열리지 않았다.
해결책 모색
애초에 나는 application-test.yml, application.yml을 나눠놓았다.
그래서 application.yml 에서
spring:
profiles:
active: test
를 하고 애플리케이션을 실행시켜서 h2 console에 들어갈 수 있었다.
그 결과, 실제 어떻게 Flyway가 디비에 적용시켰는지, 왜 jpa가 매핑을 못시키고 있었는지 원인을 알 수 있었다.
원인
테이블들이 기본적으로 uppercase로 적용 되어 있었다.
적용
원인을 해결하기 위해
datasource:
url: jdbc:h2:mem:skka-for-test;MODE=MYSQL;DB_CLOSE_DELAY=-1;DATABASE_TO_LOWER=TRUE
결과
맨 뒤에
;DATABASE_TO_LOWER=TRUE
을 추가 해주니까 됐다.
'난중(개발)일기 > 삽질기록' 카테고리의 다른 글
[H2] org.h2.jdbc.JdbcSQLSyntaxErrorException: Values of types "BOOLEAN" and "TIMESTAMP(6)" are not comparable; (0) | 2023.02.27 |
---|---|
lock을 분명 걸었는데 그렇지 않은 결과가 나올 때 (0) | 2023.02.26 |
SKKA 프로젝트 하고 느낀점(feat. NCP) (0) | 2023.02.09 |
환경변수 설정으로 프로젝트에서 중요 정보 숨기기 (0) | 2023.02.08 |
[NCP] NCP API 사용기 (SourceBuild 빌드 시작 트리거 날리기) (1) | 2023.02.08 |