Configurable DB Schema Name

[mwodahl]

PR Details

Description

This PR modifies the cv-manager API to use a configurable database schema name instead of "public". By default the database schema used will still be "public", however, this allows a user to specify a different name if necessary. This issue arose during the WyoCV deployment of the cv-manager.

How Has This Been Tested?

These changes have been tested locally using docker compose. Additionally, all unit tests were verified to pass.

Types of changes

• [ X ] Defect fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that cause existing functionality to change)

Checklist:

• [ X ] My changes require new environment variables:
  • [ X ] I have updated the docker-compose, K8s YAML, and all dependent deployment configuration files.
• [ X ] My changes require updates to the documentation:
  • [ X ] I have updated the documentation accordingly.
• My changes require updates and/or additions to the unit tests:
  • I have modified/added tests to cover my changes.
• [ X ] All existing tests pass.

[dmccoystephenson]

question (blocking): There are still direct references to the public schema in the SQL scripts located in the resources/sql_scripts directory and in the resources/kubernetes/cv-manager-postgres.yaml file. Should we make these references configurable as well?

[dmccoystephenson]

question (blocking): does this line need f as well?

[drewjj]

It definitely should.

[drewjj]

I am not entirely convinced this should be customizable. I do see how leaving it as the default public schema name may not be desirable. In my opinion we should probably just change it to something custom instead of allowing complete customization.

The way this is implemented is great because it does support the customization of the pg schema but I think it is a little too free form to expect the implementer to ensure their SQL scripts get rewritten to ensure the database is built out properly. It seems possible to use psql variables to possibly achieve this but it seems like it would probably need to be done with some sort of shell script.

[payneBrandon]

ted is great because it does support the customization of the pg schema but I think it is a little too free form to expect the implementer to ensure their SQL scripts get rewritten t

Different DOTs (WYDOT in this case) will have requirements to deploy this system within an existing pg schema. If we have a better way of doing that we can definitely dive into it?