Database schema updates
The table below lists the updates made in recent releases to both the EDDS and Workspaces database schema.
For previous versions of our database schema updates, please visit the following knowledge base articles on the Relativity Community. Note that you'll need valid Community credentials to access this content. For versions earlier than Relativity 10.0, simply search by version number in the Community.
Database schema updates table
The following table lists all database schema updates made for Relativity Server 2021:
|Database||Table affected||Change type||Change details|
This represents a queue table that keeps track of jobs which populate our Analytics Engine with extracted text data. The columns of the commit were added to help keep track of metrics that we use for reporting.
|EDDS||CaseStatisticsFileInfo||Addition||When the Toggle “Relativity.Core.Toggle.CSMFileInfoCollectionRelOneToggle” is enabled, this table collects information on a workspace’s NativeType files as a part of the Case Statistics Manager run. Billing information is reported back via SUM.|
|EDDS||AnalyticsIndexC4PopulationJob||Addition||Job queue table for Relativity Analytics Index Population Manager agent. This agent is used for index population phase for C4 Analytics Indexes.|
|EDDS||ConsistencyCheckerQueue||Addition||This table is added to keep track of workspaces that need to be checked for data integrity of Data Grid File System (DGFS).|
|EDDS||PostDeleteAuditWorkspaceCleanup||Addition||This is table is added to keep track of the deleted workspaces with Audit app installed. Audit agents clean up the Elasticsearch indices after specified threshold. This is to enable delayed deletion of Elasticsearch indices.|
|EDDS||AuthenticationUserTableBackupRecord||Removal||No longer needed, was a backup for an upgrade|
|EDDS||ActiveLearningProjects||Modification||Added AgentName column to store the name of the Active Learning Manager agent currently processing a project to prevent other instances of this agent type from processing project at same time.|
|EDDS||ApplicationServer||Modification||Made a step towards Near-Zero Downtime for Custom Page deployment (part of the Aero scope of work). The purpose was to only redeploy a Custom Page if the file hash for the Custom Page had changed. As part of this, we added a FileHash column to the ApplicationServer table to track the file hash of the deployed Custom Page ZIP. Now assuming a RAP is updated with exactly the same Custom Page ZIP file, the customer will not experience downtime for the Custom Page because it will not be redeployed.|
|EDDS||AssemblyAgentType||Modification||Was meant for a P3 defect, which was causing dead locks while using the Document Viewer. We determine that the table lacked adequate indexing. The primary key was against the ID column which is seldom used in queries. More commonly, queries are done against AssemblyArtifactID and AgentTypeID, so we recreated the primary key against those two columns. We also applied a second, standard index on the same columns in reverse.|
|EDDS||FederationMapping||Removal||Migration of Secret to secret store|
|EDDS||FileOperation||Modification||Improved handling failure scenarios of in-progress File Operations. Added ROSE correlation ID to File Operation to improve logging.|
|EDDS||User||Modification||Modified to improve the user experience for the Distributed Job Framework. In the past for a distributed job when adding/removing a user from a group, deleting a user, or deleting a group when that job fails or completes an email is sent out to the user who kicked off the job. The change and the goal of the epic was to make that functionality configurable, so a user can opt in to either receiving all emails, no emails, or only failed job emails.|
|Workspace||SerializedPipelineConfig||Addition||This table keeps track of a serialized text filter pipeline configuration, which gets sent to multiple different backend services that use it to declutter textual data before using it during an analysis phase.|
|Workspace||AnalyticsIndexMetadataRepository||Modification||This change was made to be able to identify the previously populated index. Tracking this allows the application to skip population when an incremental population that only removes documents is run.|
|Workspace||ContentAnalystCluster||Modification||This column references a configuration container that holds relevant job config data. It gets sent to a backend clustering job that produces LSI clusters for client visualization.|
|Workspace||DynamicReviewMetadata||Modification||This change was made to facilitate multiple versions of Dynamic Review Queue schema. A version column was added to the review queue metadata table to track which version each review queue instance is using.|
|Workspace||AnalyticsC4IndexBuildJob||Addition||Stores progress details and job execution metadata for C4 Analytics Index build jobs.|
|Workspace||ReproductionHistory||Addition||Stores the mapping of a re-production artifact id to its production artifact id, along with the name and date produced as a record in case the re-production is later deleted.|
|Workspace||AnalyticsCategorizationSetBuildHistory||Modification||Removed Confidence field from this object type as it is no longer used.|
|Workspace||AnalyticsIndexMetadata||Modification||Added various columns to store metadata for C4 Analytics engine jobs and workflows.|
|Workspace||ContentAnalystCluster||Modification||Added various columns to store metadata for C4 Analytics engine jobs and workflows.|
|Workspace||DataGridFileMapping||Modification||Added CheckedForConsistency column to support file consistency checker|
- SQL Access Is Not Recommended. Due to risks, Relativity strongly recommends that customers use the APIs and other Relativity Admin-Dev Tools rather than seeking direct access to the SQL server backend and data store for Client’s Relativity Instance.
- User Training and Risks. SQL Access requires advanced technical knowledge, and using SQL Access substantially increases the risks of data destruction, loss or corruption, and Relativity system degradation, interruption or failures. Improperly using SQL Access carries substantial risk of destruction of data and degradation or possible interruption of Relativity; and Relativity shall not be liable for any mistakes, errors, or other unintended consequences of using SQL Access. If Relativity provides any certificates, passwords, and other credentials (“Client Access Credentials”) in connection with SQL Access, Client is solely responsible for managing the security of Client Access Credentials, and Relativity will not be liable for any unauthorized access or improper use of such Client Access Credentials.
- Compatibility and Other Risks. Relativity periodically updates and modifies Relativity, including SQL, in Relativity’s discretion. Relativity: (a) makes no guarantee that the SQL BD Schema update provided herein is free of errors or that there will be compatibility of updates to Relativity with any developments, integrations or other actions that Client or its vendors take based on their SQL Access; and (b) will not be liable the SQL BD Schema update provided herein contains errors or if Relativity’s updates and modifications to Relativity are incompatible with existing and under-development applications, integrations or other actions that Client or its vendors have taken in using SQL Access.
- Sandbox Testing. Client or its vendors shall thoroughly test for continuing compatibility and shall resolve any resulting compatibility issues (preferably including a high quality automated program). If Client or its vendor discovers any errors or issues with Relativity or the SQL BD Schema update provided herein, Client should promptly send an email with relevant details to email@example.com. Relativity provides a Sandbox Test Environment for integration and functional testing and validation of code, Relativity Custom Applications, extensions, and integrations created by Client or its vendors (“Sandbox Test Purpose”). The Sandbox Test Purpose does not include performance testing or any development work beyond testing. Note that: (a) the Sandbox is a scaled-down, limited version of Client’s Relativity Instance; (b) for avoidance of doubt, Relativity Availability SLA provisions are not applicable for the Sandbox, which may need to be “turned on” and will be available only while in use by Client.
- Other Client-Related Problems. Relativity is not responsible for Relativity issues, errors, loss or corruption of Client Data, or events or problems degrading or interrupting Relativity Availability, caused by Client’s personnel, its other enabled users, its third party vendors or their products or services in improperly using SQL Access (“Client-Related Problems”). Any lack of Availability arising from any Client-Related Problems shall be Excused Downtime and shall not count for purposes of determining service credits. However, in such event, Relativity will assist Client by providing a “Data Restore” procedure. In addition, upon Client’s request, Relativity will use reasonable efforts to provide Client and Client’s third party vendors with temporary limited direct access (“Limited Direct Access”) to applicable resources in the Relativity infrastructure to the extent necessary to troubleshoot issues with any of their Relativity Custom Applications which are publicly listed on Relativity’s website, provided: (a) Client and/or Client’s third party vendors have already made reasonable efforts to resolve the issue; (b) Relativity infrastructure Limited Direct Access will be supervised by Relativity Support and will not involve any access to PaaS resources; and (c) Relativity infrastructure Limited Direct Access otherwise complies with the terms of a standard operating and security procedure which Relativity may develop from time to time for handling such requests. Any support that Relativity provides in seeking to help resolve a Client-Related Problem shall not be covered by Relativity support obligations and Client may be required to pay Relativity’s then applicable standard hourly rates.