Managing databases tables

From FMR Knowledge Base
Jump to navigation Jump to search

The Registry persists information, such as settings and structural metadata to a database. The only time you may need to directly modify this database without using the Registry User Interface is to possibly remove unwanted logging information. It is recommended to NOT modify database tables unless explicitly instructed to do so.

Logging Tables

Auditing and Logging in the Registry can produce large amounts of data, which is stored in the following 3 tables:

  • registry_audit
  • registry_logs (Fusion Registry 10 only)
  • registry_logs_zip (Fusion Registry 10 only)

The table registry_audit stores Audit information for requests received directly to Registry Web Services (e.g. the Data Transformation Web Service) as well as calls directly to the GUI and any Web Services that are called as direct consequence of that (e.g. the front page of the Registry 'overview.html' calls subsequent Web Services ). The registry_logs and registry_logs_zip tables are used for storing logging information which is the information generated by the Registry logger. This information is usually output to the Apache Tomcat file "FusionRegistry.logs" but can also be stored in the database.

The information stored in these tables is not particularly visible to users of the Registry and is generally only accessible by using the "Activity" administration pages, where the information can be displayed in a modal like the following:


The information in these tables may relate to structural submission or simply a web service query. It is generally recommended to persist any requests which have a transaction ID against them as these are releated to structural submission, modification or deletion.

Removing Data from the Tables

It is permissable to delete the contents of the above tables whilst the Registry is running. If the data from these tables is removed the only effect is that requesting particular data from the activity pages may result in an error message stating that the data is unavailable.

It is recommended to preserve the data that has an associated transaction id. This allows the preservation of the information regarding who submitted or modified the structural metadata.

For the Audit table this can be achieved with:

 FROM registry_audit 

and for the logging tables:

 FROM registry_logs logs
 JOIN registry_logs_zip zip ON logs.log_uid = zip.log_uid
 WHERE logs.log_uid IN (SELECT log_uid FROM registry_logs WHERE tx_id IS NULL);