시간 데이터 타입에 대한 미숙함

CafeMate 프로젝트로 학점을 인정받을 수 있는 프로그램 참여 도중
마주한 실수를 기록하는 글이다.

발단

프로젝트 계획 단계에서 아직 DB 공부가 충분히 되지 않았다고 판단한 팀원과 나는
DB 연결 관련 기술로 Spring에서 제공하는 JDBC Template 을 활용하고 JPA 같이
개발자가 직접 쿼리를 작성하지 않아도 되는 ORM 기술을 사용하지 않기로 결정했다.

이에 따라 RowMapper 등을 사용해 ResultSet에서 필드 값을 꺼내올때 직접 타입
매칭을 시켜주어야 하는 코드를 다 구성하느라 굉장히 애를 먹었는데 그중에서도
이 시간 데이터 타입때문에 굉장히 고생했다.

---

문제

처음에는 프로젝트에서 다루는 시간 데이터 타입의 필드들을 일괄적으로 LocalDateTime
으로 설정했었다. 이유는...뭔가 java.time 패키지에 들어있는 게 더 좋다고 들어서?
하지만 Resultset에서 해당 데이터를 조회할 때 getTimestamp 메서드를 이용하기에
타입 변환이 추가되어야 하는 번거로움이 있었고 해당 필드들의 타입을 일괄적으로
Timestamp로 변경하였다.

헌데 그럼에도 불구하고, DB에 값을 저장했다가 조회하는 테스트 코드가 제대로 작동하지 않았다!!

---

Java의 Timestamp와 MySQL의 Timestamp의 차이

Java의 Timestamp 타입은 64비트 정수로 값을 저장하며, 밀리초 단위까지 지원한다.
허나, MySQL의 TIMESTAMP 타입은 32비트 정수로 값을 저장하기에 표현 범위에
차이가 존재했다. 따라서, Java의 Timestamp 타입 범위에 맞게 DB에 값을 저장하려면
MySQL 5.6.4 이상 버전에서 지원하는 TIMESTAMP(6) 을 사용해야 했다.

결론

처음에는 로직상에 문제가 있는 줄 알고 다른 방식으로 변경을 하고 돌려보고..
DB에서 더 넓은 범위를 다룰 수 있는 DATETIME 타입으로 스키마를 변경해보고..
무수한 고생 끝에 이 결론에 도달했다. 정말 사소한 부분이지만, 간과했을 때 미래에
몰아칠 수 있는 에러와 예외들을 생각하면 비교적 싼 값(?)에 문제를 해결한 것 같다.