💥문제 발생 부분
<스프링 부트와 AWS로 혼자 구현하는 웹 서비스> (이동욱, 2019)
클론코딩 중...
p.306 스프링 부트 프로젝트로 RDS 접근하기배포 후 퍼블릭DNS주소:8080 페이지에 500에러가 떴다. EC2 리눅스 서버에서 nohup.out 파일부터 살펴보았다.
⛔에러 메시지⛔
java.sql.SQLException: Unknown column 'posts0_.create_date' in 'field list'
🤦 posts 테이블에는 create_date가 아니라 created_date 컬럼이 있다. (d 철자 유의) create_date 컬럼은 없는 게 당연한데 왜 이 에러문이 뜨는거야?
일단 DB에서 발생한 에러이니 RDS 설정과 DB 테이블 상태부터 확인했다.
❓접근-1) 테이블 생성 단계에서 문제가 있었는가
NOPE.
처음에는 RDS에서 대소문자를 구분하여 인식하는 문제 또한 겪었다.
AWS RDS MiraDB 의 파라미터 규칙 중,
lower_case_table_names 의 값이 1이어야 대소문자가 다르다고 데이터를 인식하지 못하는 경우가 생기지 않는다.
- 주의할 점 : 이미 테이블이 생성된 상태로 파라미터 규칙 값을 수정했다면, 해당 테이블을 drop 하고 다시 create 할 것
하지만 이 문제의 경우, column 단위가 아니라 table 단위로 인식하지 못 한다. posts 테이블 내부의 created_date 컬럼을 못 읽는 것이 아니라 posts 자체를 읽지 못하는 상황이라면 참고하면 된다.
❓접근-2) 배포 쉘 스크립트의 nohup 명령어 부분 오타인가?
NOPE.
deploy.sh 배포 쉘 스크립트 파일 가장 아래에 작성된 nohup 명령어에서 application-real-db.properties 를 비롯한 properties 연결 코드에 문제가 있는지 확인했다. 과장없이 열 번은 다시 치고 스무 번 다시 확인한 듯 ^^
application-real-db.properties 파일에 잘못 작성한 부분이 있는가 확인했지만 이 문제 역시 아니었다.
db 연결 자체에 문제가 있었다면 테이블>컬럼 을 찾지 못하는 문제는 아니었을 것이다.
🔆 접근-3) JPA dto 문제인가? ❗해결❗
사실 이미 intelliJ 에서 ctrl+shift+F 로 'create_date'라는 코드가 있는지 확인을 하고 시작했다. 그래서 프로젝트 코드의 오타 문제일 거라는 생각을 못 했다.
여기저기 삽질을 하다 뒤늦게야 다시 검색을 했다. 혹시....
이번엔 언더바를 빼고 'createdate' 로 검색을 했다.
....?
..........??
??????????????????????????????????
😇😇😇😇😇😇😇
BaseTimeEntity 파일을 확인했다.
너무나 당당하게 적혀있는 createDate .............
어쩐지....... create_date 라는 이름은 변수명으로도 db 컬럼명으로도 쓴 적이 없는데 왜 자꾸 이걸 찾나 했다.
createdDate 로 수정-커밋-깃푸시 후에 다시 EC2 서버에서 deploy.sh 를 실행했다.
정상 배포 성 공 ^^
이틀 동안 'd' 하나로 삽질했던 이야기..
또 다른 삽질이 기다리고 있다
to be continued...