You can further enhance your applications by learning about how to use advanced functionality, such as versioning. In addition, you can fine-tune your applications with an understanding of other advanced features.
This page contains the following information:
Relativity applications have two groups of components:
Hosted components are installed once regardless of the number of workspaces in the instance. They incur near-zero downtime as Relativity loads new versions of event handlers, agents, Kepler endpoints, and custom pages and wraps up current requests before shutting down previous versions. It is safe to update hosted components in a live instance of Relativity.
Each workspace has its own copy of these items. Unlike the installation of hosted components, updates to schema component may cause errors due to changes to the data model, tabs, and layouts and performance degradation due to database updates. Workspace installations should only happen during scheduled downtime.
Often a new version of an application only includes updates to hosted components while the schema component (or schema) remain unchanged and do not require workspace installations. Until Relativity 11.2, there was no way to refresh hosted components without also updating the workspaces. The introduction of a schema version fixes this. With the schema version feature, applications can declare two versions in the application.xml file. The first is the existing <Version/> element which is the version of the entire application. Changes to the application version triggers updates to the hosted components. The second is the new <SchemaVersion/> element. It applies only to the schema component. If the incoming schema version is higher than the value in the workspace, the ADS will schedule workspace installations; otherwise they are skipped.
The schema version allows application developers to control when schema component are updated. They can keep the same value to push through updates to hosted components without affecting workspaces resulting in better performance and near-zero downtime.
You can use application versions to manage the development, installation, and upgrading of Relativity applications. Relativity uses the format Major.Minor.Build.Revision to version applications. It automatically assigns a version number to an application if you don't specify one during creation. The default version number is 0.0.0.1. See Create an application in Relativity.
You can edit an application version by modifying the major, minor, or build number. The new version number must be greater than the current version. However, you can't change the revision number in a version. During the export, Relativity automatically increments the revision number if the application has undergone any modifications. It increments the revision number if you performed any of the following actions:
In addition, the following application components use these versioning practices:
During an upgrade, Relativity uses the following criteria to determine whether to perform a full or incremental installation of an application in a workspace.
Relativity performs a full upgrade when the following conditions are true:
Relativity performs an incremental upgrade by installing only new or modified application objects and dissociating obsolete objects. Incremental upgrades run faster because they only perform updates to address changes that exist between the current version of the application and the new version that you are installing.
It performs this type of upgrade when the following conditions are true:
The following rules control tab behavior during initial installation and upgrades:
Note: If you previously built an application with a parent tab, upgrading to Relativity 6.10 or above automatically removes the tab.
Depending on the version of Relativity, Relativity treats object type event handlers differently during application upgrades.
When upgrading an application to a newer version, if the new version of the application no longer contains the event handler (but previously did), Relativity removes the event handler from the object type. You don't have to write custom code to remove the event handler association from the object type.
If the new version of the application no longer contains an object type event handler, the event handler is removed from the application but the object type association persists. You can remove the event handler from the object type by writing a post install event handler.
Before July 2017, the files associated with older versions of applications remained in place following upgrade and required special programming logic to delete. This complicated development and the upgrade process.
Beginning in July 2017, the application upgrade process purges assembly resource files (DLLs) no longer associated to the newer application version:
The following application components are not deleted by the upgrade process:
You can also manually delete DLL resource files from the Resource Files tab in Developer Mode without having to unlink your objects from all workspaces.
Community Updates |
|||
Aero Developer FAQ | Evolving the Platform | Most recent release notes | |
Learn more | Learn more | Learn more |
Additional Resources |
|||
![]() |
![]() |
||
Access Third-Party Tools with GitHub | Create .NET Apps Faster with NuGet | ||
Visit github | visit nuget |