Registry data model tables and their structures

The General tab provides basic information about the table, allowing a superficial understanding of the purpose of the table, as well as some of its attributes, namely:

This checkbox has been removed in 1.9.2. See NOTE.

The Indexes tab allows viewing the list of indexes for a specific table in the database, as well as the rules by which they operate.

The modeler can also sort the indexes by name and the rule applied to the index when searching for data.

Pagination option (paging) is also available if the number of records with indexes exceeds 10 per page.

The Columns tab allows you to view the structure of columns in a specific table of the registry database.

When working with registry data, a temporary replica is created and deployed for each candidate version from the reference database (PostgreSQL). The reference database contains only the structure without any registry data.

The regulations deployment subsystem (regulatory Jenkins) creates the database structure by deploying the liquibase configurations of the registry regulations. For more details, see Creating a physical data model.

The Registry regulations management subsystem (registry-regulations-management) reads the data model structure of the temporary database and saves it as a snapshot of the current state of the data model to the DataModelSnapshot file in JSON format. Later this data is passed to the Regulations administrator portal, where the current state of the database tables is displayed for each candidate version.

After successfully generating the temporary database for a specific candidate version, the administrator can work with the created replica and view all the tables and their structure in the Tables section of the Registry regulations administrator portal.

The general interface of the Regulations administrator portal for master and candidate versions when working with tables is the same (see General overview).

During the deployment of temporary databases, the operability of the existing liquibase changelog configuration of the registry regulations is also checked. During this process, information about the execution status of the corresponding Jenkins pipeline is passed to the Regulations administrator portal.

The deployment status of the temporary database is published to the corresponding merge request (MR or change request to merge the changes into the master branch) in Gerrit.

The Registry regulations management subsystem reads the deployment status of the registry regulations (liquibase deployment) from the corresponding merge request in Gerrit. The execution status of the corresponding pipeline is displayed in the Gerrit merge request for the candidate version using specific labels:

When working with registry data, a temporary replica is created and deployed from the reference database (PostgreSQL) for each candidate version. Often, this leads to a situation where the candidate branch may have been deleted, but the temporary database continues to exist and utilizes registry resources.

To address this issue, a special reconciliation process has been implemented to periodically remove outdated database schemas based on candidate versions (candidate versions that have been integrated/merged into the master version or those that have been deleted without integration).

Reconciliation process (cleanup-of-version-candidate-db pipeline) is a Jenkins process scheduled to run at a specific time. The frequency parameter for triggering the process is configured at the helm configuration file level of the registry and passed to the Jenkins pipeline trigger level. The default value is once a day at 17:00 GMT+2 (Kyiv time).

After running the cleanup-of-version-candidate-db process, the system deletes all temporary databases that are not in an "Open" status in Gerrit.