System Update Recommendations

When working with application systems using Foresight Analytics Platform, several repositories located in development, testing, and production environments are used to divide development processes. When a project is developed, application system objects are often changed, and the system composition is frequently modified (objects are added or deleted).

Using the update one can make changes in the cloned target repository. A cloned repository is created using a saved copy. A cloned repository is created by means of appropriate DBMS.

The example of update process in two stages:

Create an update in the source repository in the development environment.
Update the target repository in the testing environment.

An update is a *.pefx file (Platform Export File Extended) that contains various information on changes made in application system objects.

Each repository object has unique numeric code that identifies the object. These codes are stored in system tables, which also contain full information on objects and their relationships. The source and target repositories have the same unique codes for the same objects. If a repository is not target, the internal codes of update objects and repository objects may not coincide during the update, but overlap during the additional process, which will lead to conflicts.

During the update take into account object version check if the Object Version Control on Update checkbox is selected in the security manager.

NOTE. It is recommended to update object versions only for target repositories.

The main reasons not to update different repositories are:

Coinciding objects' internal codes.
Coinciding objects' identifiers.
Protecting against the creation of new objects with existing internal codes.

An exception might be the case when objects need to be moved to an empty repository.

It is recommended to install updates in the production environment during system idle time or in the absence of active users. The most of repository objects after update do not require additional operations and are ready for use. One can also clear cache and restart BI server.

If the created infrastructure does not allow for stopping system work and restarting BI server, take into account some features related to work of assembly cache and system table cache. Assembly cache is used by all development environment objects: assemblies, units, forms, and web forms.

Assembly cache:

Fore code changes made during user work will be applied only after unloading and repeated loading of complied assemblies. In case of event handler, one will need to close all objects, which use this handler, to apply new code.
Assemblies/units, which code uses static class fields, are unloaded only after exiting the repository, that is why one should log in to the repository again to apply code changes.
When installing development environment object updates it is prohibited to use the Set Date Modified from the Update parameter. It is related with the fact that compilation date and time are stored in assembly cache. To enable recompilation, date and time in cache should be earlier than date and time of object modification in the database. As the database stores time from the update, this condition may be impossible to fulfill. If it is required to install update with the selected checkbox Set Date Modified from the Update, after applying the update it is required to force clear assembly cache on all BI servers.

System table cache:

When installing updates to the repository, in which system table cache is enabled, it is required to update system table cache. Methods for clearing current cache an creating a new cache are available in the IMetabaseManager interface in the Fore language.
If there are active users in the system during clearing and updating cache, requests are executed to system tables in the database until cache is recreated.