사용한 기술: hibernate listener, envers
데이터의 이력 정보를 담은 api를 만드는 작업을 했다.
데이터는 회원 정보라고 하자.
회원 정보도 5000 정도 쌓였고, 회원 정보 수정 이력도 20000 정도 쌓였다고 가정한다.
회원 정보 테이블, 회원 정보 수정 이력 테이블 두 개가 있다.
회원 정보 수정 이력 테이블은 hibernate envers를 활용하여 구현했다.
회원 정보 수정 이력을 각 회원에게 보여줄 수 있도록 한다.
회원 정보 수정 이력 api의 구성은 대략 다음과 같다.
( 회원 id, 이력 변경의 종류, 바뀌기 전 정보, 바뀐 후 정보)
회원 정보 수정 이력 테이블이 있으니, 그 테이블을 이용하여 쿼리를 짜면 쉽게 끝날 것 같다.
하지만 쉽지 않았다.
단순한 스냅샷으로는 요구사항을 만족할 수 없다
기존 회원 정보 수정 이력은 수정한 순간의 '회원 정보'를 저장하고 있다.
즉 데이터 구조는 회원 정보 테이블과 같다.
새로운 요구사항은 '변경 전 정보'와 '변경 후 정보'를 한 개의 행에 같이 보여주는 것이다.
그리고 특정 변경 이력만 보여준다. ( ex 회원 닉네임 변경 이력은 보여주지 않는다)
새로운 요구사항을 만족시키려면 추가적인 계산이 필요하다.
1) 한 회원에 대해 '특정 조건'에 맞는 수정 이력을 조회하고,
2) 수정 이력 하나 당 바뀌기 전 값과 바뀌기 후 값을 계산한다.
1) 부터 쉽지 않다. '특정 조건'에 맞는 수정 이력을 쿼리로 조회하려면, 쿼리 단계에서 변경 전 데이터와 변경 후 데이터를 비교하는 계산이 추가되어야 한다.
그러려면 쿼리로 대상 이력과 그 이력의 직전 이력을 추출해서, 두 이력의 데이터 값을 비교해야 하는데, 쿼리로 짜는 방법을 모른다.
기존 테이블을 활용하여 쿼리를 만들지 않고, 새로운 요구사항에 맞는 테이블을 만들었다.
새로운 테이블
새로운 테이블은 다음과 같이 구성된다.
( 회원 id, 이력 변경의 종류, 바뀌기 전 정보, 바뀐 후 정보)
새로운 요구사항과 일치한다.
Hibernate의 listener를 사용하여, update 시 특정 조건이 맞았을 때만 새로운 테이블의 형식으로 데이터가 쌓이도록 한다.
위와 같이 구성하면, 그 이전 회원 이력 테이블을 활용하지 못한다.
새로운 테이블이 배포되기 전까지 회원 정보 변경 이력을 사용자에게 보여주지 못한다.
기존 테이블 데이터를 새로운 데이터 형식에 맞게 복사하는 방법도 있지만, 그렇게 하지 않았다.
더 잘하려면
- 어떤 데이터의 이력 테이블을 만들 때, 단순히 데이터의 스냅샷을 찍지 않고, 추가적인 데이터를 넣는다. 보통 사용자는 이력을 볼 때 바뀌기 이전 값과 바뀐 이후 값을 궁금해 한다.
- 이력 테이블에 before, after, 바뀐 데이터 column 이름 등을 column 으로 추가할 수 있다.
- 개발 우선순위를 정할 수 있으면 좋다.
- 기획 히스토리를 알면 개발 우선순위를 정하는 데 도움이 된다.
