search

SolutionGuidance / psm

Welcome to the Medicare/Medicaid Provider Enrollment Screening Portal
http://projectpsm.org/
Other
26 stars 20 forks source link

Update liquibase gradle plugin #982

Closed slifty closed 6 years ago

slifty commented 6 years ago

The gradle plugin for liquibase that we were using got updated to a 2.0 release. The big benefit of the new version is that liquibase is no longer packaged as a dependency. This provides much more flexibility around the version of liquibase that actually gets used by the project, as we can pick it ourselves.

As a result we needed to add liquibase as a dependency, and move the database dependency to the db project.

There are also some changes around which root directory gets cited; resulting in required changes to the way changesets and seed files are referenced across the migration-related paths.

NOTE: this PR still has us NOT using the latest version of liquibase (3.6.x). Instead it uses 3.5.x. This is because 3.6 introduces a change that would make our pending seed data improvement more verbose than we would like. I've filed an issue in liquibase JIRA for their consideration

IMPORTANT: the changelog location had to change because of this upgrade, and as a result we have to make an edit to the databasechangelog contents so changesets aren't run a second time. Specifically:

UPDATE databasechangelog set filename='changelog/db-changelog-1.0.xml' where filename='db/changelog/db-changelog-1.0.xml'

This PR also includes code to refactor the way seed data is migrated. This refactoring would normally be a separate PR but they both impact past migrations so we decided to combine them into a single PR to minimize deployment drama.

before switching / pulling this branch, run ./gradlew db:update, then switch, then run ./gradlew db:changelogSync

Resolves #980 Improve the way seed data is migrated Resolves #981 Update liquibase gradle plugin to 2.0

jasonaowen commented 6 years ago

Yesterday, we discussed on Zulip a small complication with how the CSVs are being loaded. We plan to change how those are loaded, and that will also mean a manual migration step. @slifty and I decided that it would be better to have a single, larger PR than two smaller PRs so as to reduce the deployment impact.

Here is the plan for loading seed data:

  1. delete the seed changelog
  2. move all seed based change sets into the 1.0 changeset
  3. change all seed imports from loadUpdateData to loadData
  4. rename all the seed files to have the date prepended

I believe @slifty is planning on adding commits to implement that plan to this pull request.

jasonaowen commented 6 years ago

@slifty, is this the last of #980 and #981? If so, please edit the PR description to include the resolves magic word so that GitHub will close the issue(s) when this PR is merged.