26.2. Data history functionality structure

Data history is stored in special tables of the same infobase for which versioning is set. In addition to the data itself, the data history also stores metadata of previous versions of versioned objects. Version of metadata of the object is created at the time of change of the object's metadata. The moment of creation of the metadata version has nothing to do with changing the data of the versioned object. The data history does not store the types of attributes, but only the actual values of these attributes. It should also be remembered that from the point of view of the system, the following pairs of actions are the same:

• Enable attribute versioning and create a new attribute.
• Disable attribute versioning and delete the attribute.

In addition to storing the changed versioned object data, versioning allows specifying a special comment and additional data for each version. This data can be used upon subsequent analysis of changed data.

The process of forming a version consists of several steps:

1. System records an object change. This occurs either automatically or by calling a method in the program interface. Information about the object change is transferred to a special queue (version queue). At this point, you can add an arbitrary data required for subsequent operations to the versioned data (the WriteDataHistory.AddAdditionalData() versioned object method).
   Data is transferred from the version queue to the database tables that actually store the version data. This operation is performed with the help of the DataHistory.UpdateHistory() method. You can update the data history asynchronously, for example, by using a scheduled job. The process is similar to updating the full-text search index. In other words, the data version becomes "real" only after it is moved from the queue of versions to the tables of history storing. In this case, several consecutive changes to the data object (no matter how these changes are made) are recorded separately and transferred separately. So, all changes to data objects are recorded in the data history, regardless of the frequency of history updates and the number of consecutive changes to one object. Each processed data version will be transferred to a special queue of versions requiring processing after the version saving (post-processing queue). The necessity of such transfer is defined by the WriteDataHistory.ProcessAfterWriting versioned object property.
   Post-processing queue processing begins after the version queue processing completion. This processing can be performed by the DataHistory.UpdateHistory() method and the special DataHistory.ExecuteAfterWriteVersionsProcessing method. The processing itself shall be performed in the AfterWriteDataHistoryVersionsProcessing() handlers of the versioned object manager modules.
   After the version post-processing completion, delete the version from the post-processing queue with the help of the DataHistory.DeleteFromAfterWriteVersionsProcessing() method. If you do not do it, this version will be constantly transferred to the AfterWriteDataHistoryVersionsProcessing() event handlers.
   To clear the post-processing queue, use the DataHistory.DeleteFromAfterWriteVersionsProcessing() method.

The first two steps of the description above are compulsory and always performed in the process of data version formation. The subsequent steps are used only when the developer wants to use the post-processing queue.

You also need to keep in mind that there are two methods one can use to generate data history: the usual method described in this section and an accelerated method. In the second case, it is possible to initiate the whole process of a data version writing but only for one version of one data object. This processing method will be described in more details separately.

Versioning can be set in two ways:

1. In Designer.
   1. From 1C:Enterprise language.

It is reasonable to use Designer to set data history if the application developer is sure that the data history for an object will be required in any system operation mode or some application logic is tied to this history.

If data history is used to monitor infobase operations and to answer the question "why so?", it makes sense to implement data history enabling in 1C:Enterprise language so that the application user could select objects and attributes for which versioning is required. Remember that enabling data history from 1C:Enterprise language does not require disabling the configuration support.

To enable data history for an object in Designer, set the Data history property for this object to Usage. After that, create a scheduled job that will update the data history in the order of changes. The same property is present in subordinate configuration objects: attributes (standard and usual), tables and their attributes, and resources of information registers.

By default, the Data history property is set to the following values:

• For catalogs, documents, charts of characteristic types, charts of accounts, business processes, tasks, information registers: Do not use.
• For standard attributes: Use.
• For objects attributes: Use.
• For table attributes: Use.
• For information register dimensions: Use. It is impossible to change the value.
• For information register resources: Use.

Thus, for the type-forming configuration objects, a logging should be enabled forcibly, and all the attributes of such objects automatically fall into the history and it is necessary to forcibly exclude these attributes from the history.

Operations with data history will be discussed in the next section.