google-nomulus/db
Weimin Yu 04b076eb0a Add RegistryLock schema to Flyway deployment folder (#270)
* Add RegistryLock schema to Flyway deployment folder

Added creation script of RegistryLock to Flyway deployment folder.

Fixed previous scripts (PremiumList- and ClaimsList-related) for
FK name change (cause by table name changes: names are quoted now).
We should consider generating foreign key names by ourselves.

Since the alpha database is empty, we dropped and recreated the schema.

Added instructions on how to submit new database incremental changes
in the README file.

Updated RegistryLock.java, removing unnecessary annotations:
- For most fields, the 'name=' property is no longer necessary not that
  the naming strategy is in place. The exceptions are the two used in
  the unique index.
- The @Column annotation is implicit.
2019-09-16 16:47:58 -04:00
..
gradle/dependency-locks Use Flyway to deploy SQL schema to non-prod (#255) 2019-09-06 16:29:49 -04:00
src Add RegistryLock schema to Flyway deployment folder (#270) 2019-09-16 16:47:58 -04:00
build.gradle Add schema deployment tests (#265) 2019-09-12 15:16:12 -04:00
README.md Add RegistryLock schema to Flyway deployment folder (#270) 2019-09-16 16:47:58 -04:00

Summary

This project contains Nomulus's Cloud SQL schema and schema-deployment utilities.

Schema DDL Scripts

Currently we use Flyway for schema deployment. Versioned incremental update scripts are organized in the src/main/resources/sql/flyway folder. A Flyway 'migration' task examines the target database instance, and makes sure that only changes not yet deployed are pushed.

Below are the steps to submit a schema change:

  • Define the incremental DDL script that would update the existing schema to the new one.
  • Add the script to the src/main/resource/flyway folder. Its name should follow the V{id}__{description text}.sql, where {id} is a number that is higher than all existing scripts in that folder. Also note that it is a double underscore in the naming pattern.
  • Run :db:tests from the Gradle root project. The SchemaTest will fail because the new schema does not match the gold file.
  • Copy db/build/resources/test/testcontainer/mount/dump.txt to the golden file (db/src/main/resources/sql/schema/nomulus.golden.sql). Diff it against the old version and verify that all changes are expected.
  • Retrun :db:tests. This time all tests should pass.

Relevant files (under db/src/main/resources/sql/schema/):

  • nomulus.golden.sql is the schema dump (pg_dump for postgres) of the final schema pushed by Flyway. This is mostly for informational, although it may be used in tests.
  • db-schema.sql.generated is the schema generated from ORM classes by the GenerateSqlSchema command in Nomulus tool. This reflects the ORM-layer's view of the schema.

The generated schema and the golden one may diverge during schema changes. For example, when adding a new column to a table, we would deploy the change before adding it to the relevant ORM class. Therefore, for a short time the golden file will contain the new column while the generated one does not.

Non-production Schema Push

To manage schema in a non-production environment, use the 'flywayMigration' task. You will need Cloud SDK and login once.

# One time login
gcloud auth login

# Deploy the current schema to alpha
gradlew :db:flywayMigrate -PdbServer=alpha

# Delete the entire schema in alpha
gradlew :db:flywayClean -PdbServer=alpha

The flywayMigrate task is idempotent. Repeated runs will not introduce problems.

The Flyway tasks may also be used to deploy to local instances, e.g, your own test instance. E.g.,

# Deploy to a local instance at standard port as the super user.
gradlew :db:flywayMigrate -PdbServer=192.168.9.2 -PdbPassword=domain-registry

# Full specification of all parameters
gradlew :db:flywayMigrate -PdbServer=192.168.9.2:5432 -PdbUser=postgres \
    -PdbPassword=domain-registry

Production Schema Deployment

Schema deployment to production and sandbox is under development.