개발 단계에서 페이징 처리 등 시드 데이터가 필요한 경우가 더러 있다. 이 때 Flyway 에서 제공하는 Repeatable migration 을 활용해 시드 데이터를 관리하면 어떤 점이 편한 지 그리고 유의할 점은 무엇이 있는 지 알아보자.
Repeatable migrations have a description and a checksum, but no version. Instead of being run just once, they are (re-)applied every time their checksum changes.
Repeatable migration 의 가장 큰 특징은 checksum 값 (= 변경 여부 체크하는 값) 이 변경된 경우 여러 번 migration 이 적용된다는 점이다. SQL-based migration 에서 Repeatable migration 을 사용하기 위해서는 R__{description}.sql 와 같은 파일을 생성하는데, 이미 migration 처리된 파일을 수정하면 checksum 값이 변경 되면서 해당 파일의 내용이 다시 migration 처리 대상이 된다는 것이다.
위와 같은 특징으로 별도의 버전 정보를 따로 관리하지 않는다.
시드 데이터를 관리할 때 Versioned migration 보다 Repeatable migration 을 사용하면 편리한 이유도 위에서 언급한 특징에서 찾을 수 있다. Versioned migration 은 버전, 즉 특정 시점의 상태 정보를 가지고 있고 따라서 딱 한 번만 migration 처리가 된다. 따라서 시드 데이터를 Versioned migration 으로 관리하면 시드 데이터의 추가 및 삭제 시 계속 해서 파일을 생성해서 대응해야 한다.
반면, Repeatable migration 은 별도의 파일 추가 없이도 하나의 파일 내에서 관리가 가능하다는 점에서 상대적으로 효율적이라 할 수 있다.
[ 그림 1 ]
예를 들어, USER 테이블에 USER 1, 2, 3 을 넣고 싶으면 [ 그림 1 ] 과 같이 파일을 생성하고 안에 INSERT 쿼리를 두면 된다.
[ 그림 2 ]
그리고 USER 테이블에 USER 4, 5, 6 을 추가로 넣고 싶으면 별도의 파일을 추가 생성하지 않고 동일한 파일 R__user_seed.sql 에 USER 1, 2, 3 쿼리를 지우고 4, 5, 6 INSERT 쿼리를 추가하면 된다.
[ 그림 3 ]
만약 시드 데이터를 관리할 때 [ 그림 3 ] 같이 현재 데이터베이스에 적용된 시드 데이터를 한눈에 확인할 수 있도록 일괄적으로 관리하고 싶을 때는 USER 4, 5, 6 을 추가할 때 1, 2, 3 이 그대로 남아 있게 되면 중복 키 문제가 발생 할 수 있으므로 ( id 가 pk 인 경우 ) 이 때는 최상단에 DELETE 쿼리를 통해서 여러 번 migration 되더라도 중복 키 에러를 방지 할 수 있다.
이 때 또 주의할 사항이 있는데, 테이블 내 시드 데이터를 DELETE 를 통해 모두 삭제하거나 특정 ROW 을 삭제할 때 외래 키 로 참조 관계가 맺어진 경우 참조 무결성 으로 인해 DELETE 쿼리 시 에러가 발생 할 수 있다. 따라서 Repeatable migration 을 통해 시드 데이터를 관리할 때 위와 같이 참조 관계까지도 잘 고려해서 처리하는 것이 중요하다.