Flyway로 패치 하위 집합 관리

Question

단일 데이터베이스 스키마를 사용하는 하나의 응용 프로그램이 있습니다. 그럼에도 불구하고 응용 프로그램에는 코어 (DB 객체가 있음)가 있으며 플러그인 논리 (각 DB 객체가있는 각 플러그인)로 확장 할 수 있습니다. 핵심 DB 개체 및 플러그인 DB 개체는 별개의 세트이므로 플러그인은 선택 사항이며 존재할 수도 있고 존재하지 않을 수도 있습니다.

따라서 Core 및 각 단일 플러그인에 대해 별도의 versionig 및 마이그레이션 제어가 필요합니다.

이동 경로를 사용하여이 별도의 "마이그레이션 경로"를 관리하는 방법이 있는지 궁금합니다.

내가 생각할 수있는 유일한 점은 응용 프로그램을 호스팅하는 동일한 단일 DB 스키마 (많은 다른 이동 경로 메타 데이터 테이블 (예 : schema_version_core, schema_version_plugin1 등))를 작성하고 각 구성 요소의 마이그레이션을 독립적으로 관리하는 것입니다.

이 것이 가능합니까? 더 똑똑한 제안?

많은 감사

Answer 1

이 그대로 내가보기 엔 당신이 스키마로 DB를 분할하는 것이 좋습니다 정말 그들이 무엇 : 오브젝트의 관리를 설정합니다.

이것이 옵션이 아니면 제안한 대안이 정상적으로 작동합니다. 깨끗하게 호출 할 때 조심하십시오. 그러면 플러그인 중 하나의 파트가 아닌 전체 스키마가 정리됩니다.

Answer 2

현재 동일한 문제로 고민하고 있습니다. 모든 "자체"데이터베이스 개체를 가질 수있는 여러 "기본"구성 요소로 이루어진 응용 프로그램입니다.

나는 같은 스키마에 다른 플라이 웨이 메타 테이블을 사용하는 옵션을 시도했지만 작동하지 않습니다. 플라이웨이가 처리 될 때 예 : 두 번째 모듈에 대한 두 번째 테이블은 스키마가 비어 있지 않다는 것을 발견하고 (첫 번째 모듈은 db 변경 사항을 마이그레이션했기 때문에) flyway가 db 및 해당 마이그레이션 상태를 결정할 기회가 없으므로 중지됩니다.

또한베이스 라인 버전을 사용하면 기본 모듈의 변경 사항이 다음 모듈에서 생략되므로 도움이되지 않습니다 ... 플라이 웨이가있는 유일한 합리적인 솔루션은 다른 스키마를 사용하는 것입니다 ... .